river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Release 2.2 comments
Date Thu, 30 Jun 2011 03:56:57 GMT
I got a QA test failure, 
com/sun/jini/test/impl/reggie/MultihomedClientTest.td. The failure is 
due to the missing 
com.sun.jini.test.impl.reggie.NameServiceDescriptorImpl class.

That leaves us with the following options:

1. Insist on Java 5 compilation, and change the code to match the Java 5 
version of the interface.

2. Delete the files, and drop one or more tests which are presumably 
testing configurations that nothing else tests.

I'm inclined towards the first answer, but not strongly.

Patricia


On 6/29/2011 2:17 PM, Tom Hobbs wrote:
> Well that's something.  A good something!  Fingers cross on the QA
> tests.  I'm just about to sign off now, but please check the deletions
> into the trunk if/when you're happy with them and I'll create some new
> RCs.
>
> If only all fixes were as simple.
>
>
> On Wed, Jun 29, 2011 at 9:56 PM, Patricia Shanahan<pats@acm.org>  wrote:
>> I've done a clean build with the classes in question deleted. It got a
>> "BUILD SUCCESSFUL". I'll start the QA tests that way, but I suggest making
>> that change. (I'm not checking in anything to the trunk right now, to avoid
>> risk of tripping up your efforts).
>>
>> Patricia
>>
>> On 6/29/2011 1:07 PM, Tom Hobbs wrote:
>>>
>>> I've just done a quick search for uses of NameServiceImpl and the only
>>> thing I could find was in NameServiceDescriptorImpl.  And I couldn't
>>> find any references for that.
>>>
>>> Given that the package is "com.sun.jini.test.impl.reggie" for both of
>>> these classes, can I assume that they're for some test only?  Does
>>> anyone know what they're for?  Can we just remove them?  (I love
>>> deleting code!)
>>>
>>> I'm sure you guys are aware of the problem, but for anyone new to the
>>> party; NameServiceImpl implements NameService which is an *internal*
>>> Sun class, which by rights we shouldn't really be using anyway.  The
>>> return type of a the lookupAllHostAddr method differs from Java 5 to
>>> 6, so we're unable to build a release that satisfies both Java
>>> versions.
>>>
>>> If we can't get around this, it looks like we might be stuck at Java 5
>>> and only 5 until we come up with something clever.
>>>
>>> This is disappointing because I was hoping to build some new release
>>> candidates tonight...
>>>
>>> Thoughts?
>>>
>>> Tom
>>>
>>> On Wed, Jun 29, 2011 at 3:41 AM, Peter<jini@zeus.net.au>    wrote:
>>>>
>>>> We have a number of uses of internal sun impl classes, I'd agree they
>>>> should all be replaced so we can expand beyond the sun implementation.  Is
>>>> there a related jira?
>>>>
>>>> If you can see a simple fix eliminating the sun dependency, go for it,
>>>> otherwise I think just fix it enough to get our release out.
>>>>
>>>> I hadn't given it further consideration last time I looked.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>> ----- Original message -----
>>>>>
>>>>> I think the problem may go deeper. sun.net.spi.nameservice.NameService
>>>>> is a sun.net interface that can change from version to version. Is it
>>>>> essential that we have our own implementation?
>>>>>
>>>>> Patricia
>>>>>
>>>>>
>>>>> On 6/28/2011 12:18 AM, Peter wrote:
>>>>>>
>>>>>> Oops, I fixed that but didn't commit, sorry  Not near my dev box,
but
>>>>>> the fix
>>>>>> is relatively simple, get byte array from each InetAddress, and return
>>>>>> byte[][] instead, can someone fix it?
>>>>>>
>>>>>> ----- Original message -----
>>>>>>>
>>>>>>> I downloaded the source, and tried a naive build on Windows XP,
>>>>>>> Cygwin.
>>>>>>> I put a JDK 1.5 bin directory at the start of my path, and ran
"ant
>>>>>>> all.build". It failed with the following errors:
>>>>>>>
>>>>>>> compile:
>>>>>>>                        [javac] Compiling 1993 source files to
>>>>>>> C:\Documents and
>>>>>>> Settings\Administrator\My
>>>>>>>
>>>>>>> Documents\River_2.2\apache-river-2.2.0-src\apache-river-2.2.0\qa\build\classes
>>>>>>>                        [javac] C:/Documents and
>>>>>>> Settings/Administrator/My
>>>>>>>
>>>>>>> Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:29:
>>>>>>> com.sun.jini.test.impl.reggie.NameServiceImpl is not abstract
and does
>>>>>>> not override abstract method lookupAllHostAddr(java.lang.String)
in
>>>>>>> sun.net.spi.nameservice.NameService
>>>>>>>                        [javac] public class NameServiceImpl implements
>>>>>>> NameService {
>>>>>>>                        [javac]                          ^
>>>>>>>                        [javac] C:/Documents and
>>>>>>> Settings/Administrator/My
>>>>>>>
>>>>>>> Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:42:
>>>>>>> lookupAllHostAddr(java.lang.String) in
>>>>>>> com.sun.jini.test.impl.reggie.NameServiceImpl cannot implement
>>>>>>> lookupAllHostAddr(java.lang.String) in
>>>>>>> sun.net.spi.nameservice.NameService; attempting to use incompatible
>>>>>>> return type
>>>>>>>                        [javac] found      : java.net.InetAddress[]
>>>>>>>                        [javac] required: byte[][]
>>>>>>>                        [javac]              public InetAddress[]
>>>>>>> lookupAllHostAddr(String host)
>>>>>>>                        [javac]
>>>>>>>                                                           ^
>>>>>>>                        [javac] Note: Some input files use or
override a
>>>>>>> deprecated API.
>>>>>>>                        [javac] Note: Recompile with -Xlint:deprecation
>>>>>>> for details.
>>>>>>>                        [javac] Note: Some input files use unchecked
or
>>>>>>> unsafe operations.
>>>>>>>                        [javac] Note: Recompile with -Xlint:unchecked
>>>>>>> for details.
>>>>>>>                        [javac] 2 errors
>>>>>>>
>>>>>>> (I'm not worried about the deprecated APIs, just the compile
>>>>>>> failures.)
>>>>>>>
>>>>>>> I next tried to find instructions. I looked at
>>>>>>> src-doc/static/build.html. It says "The bin directory of the
Java(TM)
>>>>>>> 2
>>>>>>> SDK, Standard Edition, v 1.4 (or later) must be in your executable
>>>>>>> search path."
>>>>>>>
>>>>>>> I believe we now need 1.5 or later.
>>>>>>>
>>>>>>> Patricia
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


Mime
View raw message