river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Date Tue, 14 Sep 2010 01:26:14 GMT
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.

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.



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]
>>> 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.

View raw message