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 13:01:38 GMT
I was waiting precisely to find out whether it was used or not. In the 
presence of reflection a clean compile without a class is not definitive 
evidence of non-use.

The conclusion is that it is used.

I got into this by reading and following the "Getting Started" 
instructions in the release candidate as though I had never seen River 
before and had just downloaded it in source form. Those instructions fail.

Patricia

On 6/30/2011 1:12 AM, Tom Hobbs wrote:
> If its not used then delete it now.  Why wait?  But I get what you're saying
> about the problem being more than just this file.  Is this building in 6 and
> testing in 5/6 documented on the web?  I can't remember off hand and not in
> a position to check.
>
> In any case...
>
> +1 release current artifacts (river.a.o/~thobbs/river)
>
>
>
> Grammar and spelling have been sacrificed on the altar of messaging via
> mobile device.
>
> On 30 Jun 2011 08:06, "Peter"<jini@zeus.net.au>  wrote:
>> The qa suite needs to be considered separately from the main build. It
> currently requires jdk1.6, there are other tests using sun internal
> implementations that depend on jdk 1.6.
>>
>> With source=1.4 or jsr14 it didn't matter, it still had to be compiled
> with 1.6, we bundled it into the main build in recent times, it used to have
> it's own separate make build.
>>
>> If we use source=5, target=5 we need to check it compiles and runs on java
> 6, even if it doesn't compile on 5.
>>
>> My preference:
>>
>> Compile on jdk 1.6, test on java 5 and 6, some tests will fail on 5.
>>
>> Java is bytecode backward compatible, but not necessarily source backward
> compatible.
>>
>> Forget deleting tests, this is just a distraction and side effect of using
> a very large build while trying to support a number of platforms.
>>
>> +1 release current artifacts.
>>
>> This is the best release so far with a number of fixes, lets get it out
> there.
>>
>> We can deal with this issue given proper time to consider alternatives to
> sun internal implementations, eg DI, mocking?
>>
>> File a jira, lets release, fix the qa platform compile issue later.
>>
>> Peter.
>>
>> ----- Original message -----
>>> I'm signing off for the night. Sill one failure.
>>>
>>> Patricia
>>>
>>>
>>> On 6/29/2011 8:56 PM, Patricia Shanahan wrote:
>>>> 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