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/source/vob/...

[Peter Jones <pe...@sun.com>]

On Wed, May 21, 2008 at 11:10:36PM +0000, btmurphy@apache.org 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