river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Date Tue, 14 Sep 2010 07:53:39 GMT
Yes it's a little daunting isn't it.  It would make development, 
maintenance and compatibility easier once we bite the bullet.

Any volunteers?

I had planned to release before Christmas, perhaps it should be a 
maintenance release of the last branch, until we get a modular build and 
Java 1.4 to 5 migration sorted.

Or do we let the release slip until March 2011 (1 year release) and aim 
for a modular build, supporting Java 5, or do we do both?

Peter.


Patricia Shanahan wrote:
> 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.
>>>
>>
>>
>
>


Mime
View raw message