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 Wed, 29 Jun 2011 20:56:06 GMT
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