On Wed, May 21, 2008 at 11:10:36PM +0000, [EMAIL PROTECTED] wrote: > Modified: ... > > incubator/river/qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java ... > > incubator/river/trunk/qatests/source/vob/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java
[I am curious: why update the old directory tree (trunk/qatests) as well as the new one (qatests/trunk)? This may just be my ignorance of SVN practices or how it works-- I'm unclear why the old tree is even still visible.] 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. The sun.net.spi.nameservice.NameService interface was changed for JDK 6 in a way that makes it impossible for Java source code to declare a class that can implement either the old or the new version (the return type of the lookupAllHostAddr method was changed from byte[][] to InetAddress[]). I encountered the same dilemma a few weeks ago when running the jtreg tests against some of my changes; the following files also attempt to implement NameService: source/vob/qa/jtreg/net/jini/jeri/tcp/localHostExposure/TestNameService.java source/vob/qa/jtreg/net/jini/jeri/transport/multihomed/TestNameService.java (The latter one is for testing JERI's handling of multihomed hosts, like the reggie test above tests reggie's handling of them.) Because the name service lookup mechanism indirects through a factory, NameServiceDescriptor, the name of the NameService implementation class does not need to be statically configured, so 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 ran out of time to polish this up before I committed the changes that I was trying to test, but this reminds me that I should go back and see if that makes sense to complete. 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. Of course, that's a red herring, as this particular problem isn't even about that: the tests are depending on a sun.* API, which with a different hat on I have little sympathy for-- the API was within its rights to change incompatibly, and these tests are just getting what they deserve. As the author of the two affected jtreg tests above, though, I plead guilty-- it seemed like an expedient way to get automated regression testing for this multihomed handling, not needing any special environment configured. -- Peter
