Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of pats@acm.org designates
 209.86.89.63 as permitted sender)
Message-ID: <4C8EEE86.8080809@acm.org>
Date: Mon, 13 Sep 2010 20:39:50 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
 rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
References: <4C8E86A2.2060002@zeus.net.au> <4C8EA7DA.2090605@acm.org>
 <4C8EB0CF.20203@acm.org> <4C8ECF36.6030200@zeus.net.au>
In-Reply-To: <4C8ECF36.6030200@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

What time frame are you thinking of for all this? I was a bit naive 
thinking we could easily switch to 5.

In order to make TaskManager progress, I need to pick a runAfter 
parameter type. While things are in flux, I think I'll go with 
Collection<Task>, so I can work with the jsr14 hack.

If we go to 5 for the thread package, I can do a refactoring pass to 
change to Iterable<Task>. There are a lot fewer runAfter declarations 
because of the switch to an abstract class with a default implementation.

Patricia


On 9/13/2010 6:26 PM, Peter Firmstone wrote:
> Some time back, we voted to include Java 5 language features.
>
> We didn't vote to drop support for Java 1.4 at the time and I was
> considering different options for ongoing maintenance support of Java 1.4.
>
> The last release 2.1.2, still supports Java 1.4
>
> What I'd like to consider is that the previous branch be used to
> maintain support for Java 1.4 and our next release only support Java 1.5
> onward. However an additional requirement of a distributed platform
> release, is that it plays nicely with existing Java 1.4 installations,
> which means smart proxy's still need to be compiled in Java 1.4 bytecode
> (and perhaps Service API). Service API will be already installed in the
> clients local classpath for Java 1.4 installations, but the smart proxy
> code depends on Service API and won't compile if they're Java 1.5.
>
> So while Serialization compatibility is maintained across releases, we
> just need to have compatible bytecode.
>
> Perhaps with maven provisioning there could be an opportunity for
> clients to select platform compatible bytecode at some time in the future.
>
> I guess we need to figure out how to compile the majority of classes
> using "1.5", while compiling proxy classes using "1.4".
>
> It is possible I think, to specify different class paths in the client
> jvm's of the test suite, so potentially we could test the current
> distribution with clients using the previous release and Java 1.4, while
> the server uses Java 5 or 6.
>
> This might require a separate release of the Test Suite, this would be
> useful to test binary compatibility also, very important in a
> distributed environment.
>
> This allows a migration path away from Java 1.4.
>
> "jsr14" is a build hack.
>
> To achieve this, I think we'll need to change the way we currently
> package River, to be more modular along the lines Dan Rollo has suggested.
>
> This might also be an opportunity to break out the Service
> Implementations into separate components or subprojects perhaps, each
> depending on the platform and test kit and each having it's own tests.
> Allowing one to develop on a small component of the platform and run
> only relevant tests, for faster feedback. All components might be
> assembled and run on Hudson.
>
> Possible Components:
>
> Service API. (Java 1.4)
> Jini Platform (depends on Service API) (Java 5)
> Jini libraries. (Java 5)
> Jini Security Policy.
> Test Kit
> Jini Compatibility Tests.
> Reggie
> Mahalo
> Outrigger
> Phoenix
> Fiddler
> Norm
> Mercury
>
> A client developer then only needs the Platform and Service API jar's.
>
> Then when someone creates their own djinn, they can add the services as
> they require them, reducing complexity for new developers.
>
> Regards,
>
> Peter.
>
>
> Patricia Shanahan wrote:
>> Found it. common.xml contains a macro definition, javac-cmd, which I
>> believe does the actual compilation. It defaults the -target parameter
>> to "jsr14". Changing it to "1.5" allows my Iterable construct to
>> compile, but should continue generation of java 1.5 compatible code.
>>
>> "jsr14" was an interim mode for experimentation with the 1.5 features
>> on a 1.4 JVM. It does support for-each for a Collection, but not
>> Iterable, which was added in 1.5, which explains my problem.
>>
>> Any class files that work on 1.4 should also work on 1.5, explaining
>> Peter's observation.
>>
>> Should River continue 1.4 support? If yes, we need to test on 1.4, as
>> well as 5, 6, and potentially 7. Note that there may be a performance
>> price, such as less efficient autoboxing code. If no, we should change
>> the target default to "1.5".
>>
>> Patricia
>>
>>
>> On 9/13/2010 3:38 PM, Patricia Shanahan wrote:
>> ....
>>> Here's a theory. There is some parameter (or parameters) we don't know
>>> about being passed to javac as part of the ant all.build that affects
>>> the compiler's personality. It is generating 1.5 compatible code, and
>>> rejecting a construct that I think should be accepted.
>> ...
>>> On 9/13/2010 1:16 PM, Peter Firmstone wrote:
>>>> [java] -----------------------------------------
>>>> [java]
>>>> [java] # of tests started = 581
>>>> [java] # of tests completed = 581
>>>> [java] # of tests skipped = 21
>>>> [java] # of tests passed = 581
>>>> [java] # of tests failed = 0
>>>> [java]
>>>> [java] -----------------------------------------
>>>> [java]
>>>> [java] Date finished:
>>>> [java] Tue Sep 14 01:08:05 EST 2010
>>>> [java] Time elapsed:
>>>> [java] 19953 seconds
>>>> [java]
>>>>
>>>> BUILD SUCCESSFUL
>>>> Total time: 332 minutes 40 seconds
>>>>
>>>> These test results are from qa.run executing on Java 5, so I was
>>>> expecting some test failures, knowing that the test suite doesn't
>>>> compile with JDK 1.5.
>>
>
>