river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Jones <Peter.Jo...@Sun.COM>
Subject Re: svn commit: r658927 - in /incubator/river: jtsk/trunk/ qatests/trunk/ qatests/trunk/source/vob/qa/src/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/resources/ qatests/trunk/sourc
Date Sat, 24 May 2008 04:41:23 GMT
Hi Brian,

On May 23, 2008, at 10:11 AM, Brian Murphy wrote:
> On Fri, May 23, 2008 at 1:28 AM, Peter Jones <peter.jones@sun.com>  
> wrote:
>> [I am curious: why update the old directory tree (trunk/qatests) as
>> well as the new one (qatests/trunk)?
>
> I'm not sure how much detail you want,

Thanks for indulging me.  To the point of my curiosity: your  
explanation seems consistent with my previous understanding that I  
needn't worry about the old trees (so either choice of yours was fine).

>>  I'm unclear why the old tree is even still visible.]
>
> When the new structure was put in place, Mark B said that
> at some point the old directory structure should eventually
> be removed, but that hasn't happened yet.

I see that he has just filed an issue to do that-- should remove  
confusion from browsing the source trees.

>> Anyway, I presume that the change to this NameServiceImpl class:
>>
>> http://svn.apache.org/viewvc/incubator/river/qatests/trunk/source/ 
>> vob/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java? 
>> r1=615035&r2=658927&diff_format=h
>>
>> was done so that it would compile against Sun's JDK 6. Unfortunately,
>> that makes it no longer compile against earlier Sun JDKs, like 5.0  
>> and
>> 1.4.x.
>
> Are you saying that prior to my commit, you were able to checkout
> the distribution and compile the qatests under 5.0 and 1.4.x? Or
> simply that they would compile under 1.4.x and 5.0, as long as the
> appropriate ant, make, maven, shell, etc. script or command line
> was provided?

I wasn't making any claim about the overall compilability of the  
qatests area-- I haven't tried to build it all from the River tree  
myself.

For my recent River changes, I only tried to run the jtreg suite from  
the River tree.  My changes were all in the JERI area, which has good  
coverage from the jtreg tests, and (as you may recall) the jtreg  
tests are what I am most familiar with, so I focused on running  
them.  In doing so, and running with JDK 6, I encountered this issue  
with test classes implementing sun.net.spi.nameservice.NameService--  
so when I was skimming through your commits, I gathered that you  
encountered the exact same issue with the above reggie test class in  
the regular qatests area, hence my comments about the JDK version  
dependency above.

> I was assuming, perhaps mistakenly, that no one was using the
> tests because the make files wouldn't compile the source and
> build the jar files correctly, under any jdk version. So I figured
> that being able to compile the tests under 1.6 was better than
> nothing at all. But if my assumption was wrong about how the
> tests are being used, then maybe we should back out the
> changes I made. Do you have an opinion?

I suspect that your assumption was right, and I think that it's great  
that you have put this effort into improving the situation.

>> I experimented
>> with a solution that uses a dynamic proxy implementing NameService
>> with an invocation handler that obeys whichever version of the
>> interface it determines to be in effect at runtime.
>
>> I would be happy if we could assume JDK 6, but I gather that the
>> discussion to raise the minimum even to 5.0 is still pending.
>
> Yes it is. And based on how long it took folks to agree on the
> project name, I'm guessing a discussion on the jdk version
> could take quite some time. So, since we're talking about a
> change to a test -- a single test -- not the actual River/Jini source,
> I'm not sure I'd choose to wait for the results of that discussion
> to provide a means for people to compile and run the tests;
> especially given the fact that I was under the impression no one
> was using those tests in the first place. If people are going to
> be committing changes in the future, it seems like it would be
> useful for them to take advantage of the hundreds and hundreds
> of regression tests that already exist, rather than committing
> on faith, or rolling their own test infrastructure.

Agreed, of course.  I probably shouldn't have even mentioned the  
"platform Java version" question, because as I said later, it's  
really a red herring for this particular test issue.  Evolution of  
the Java platform API, in general, should never introduce such  
incompatibility dilemmas, so it should be possible (and is  
important!) to run the tests with a later JDK version.

> That said, I'm wondering if there's a proposal implied in your
> statement above. Are you maybe proposing that the changes
> to the reggie/NameServiceImpl test be rolled back, and then
> tell folks that they have to compile the tests under 1.4.x or 1.5?
> If yes, then I'm certainly okay with that.

I'm not proposing rolling back your changes or anything else in  
particular.  I mostly just wanted to share that I had encountered the  
same problem that you had evidently encountered, although in a  
different River test suite (jtreg vs. the regular qatests), and some  
further thoughts about it.

> Admittedly, the changes I made were at best, a hack, and I made
> them because I didn't think anyone else was going to. I focussed
> on 1.6 because my company happens to rely on a number of 1.6
> features, but I'm okay with requiring 1.4.x/1.5, if that's what you
> were getting at. I just don't want to wait for the endless debates
> on the jdk version to complete.

If we have to choose one or the other, then personally, I think that  
working with JDK 6 (as you chose) is more useful at this point.  But  
I will try to look further into the hack to make it work either way.   
(It's actually less of a problem for the jtreg tests, because they  
are compiled on a per-test basis, so this problem only causes the  
affected tests to fail, it doesn't block executing the rest of the  
suite.)

Cheers,
-- Peter


Mime
View raw message