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: Migration to Java 5
Date Tue, 31 Mar 2009 08:45:12 GMT
The following is an excerpt from a Thesis by Tamara Steijger:

"Downgrading Java 5.0 Projects
An approach based on source-code
Tamara Steijger
MSI Report 08116
Växjö University ISSN 1650-2647
SE-351 95 VÄXJÖ ISRN VXU/MSI/DA/E/--08116/--SE

"...JBossRetro cannot handle anonymous implementation of abstract methods in
enumeration types... In contrast to JBossRetro Retrotranslator has no full
API support. But it can be extended easily if something is missing. It 
supports all Java
language features as well as reflection on generics and annotations. 
Furthermore, it provides
an enhanced version of the Java 1.4 collection framework. Especially, 
the support
of reflection makes Retrotranslator special".

"For projects containing reflection Retrotranslator is probably the only
solution up to now".

An interesting comparison, I think language feature support is more 
important the the full API, anyways Retrotranslator also includes some 
Java 6 API.



Peter Firmstone wrote:
> JBoss Retro, aparently supports the full Java 5 API, it's licensed 
> LGPL, but that shouldn't be a problem since we only need the binary.  
> It doesn't use ASM though.
> Peter Firmstone wrote:
>> Patrick Wright wrote:
>>>> But, I really am not sure that if we move to a "new" VM platform, 
>>>> that it
>>>> makes sense to say the new minimum is 1.5, when so many things in 
>>>> 1.5 were
>>>> fixed/corrected/enhanced in 1.6.
>>> Some specific questions I think we need to clear up:
>>> 1) should River use 1.5 language features?
>> Yes
>>        What Java 5.0 features are supported?
>>    * Generics
>>    * Annotations
>>    * Reflection on generics and annotations
>>    * Typesafe enums
>>    * Autoboxing/unboxing
>>    * Enhanced for loop
>>    * Varargs
>>    * Covariant return types
>>    * Formatted output
>>    * Static import
>>    * Concurrency utilities
>>    * Collections framework enhancements
>>> 2) should River use 1.5 specific APIs? Any limitations?
>> Yes, a subset, and yes there are limitations, see comment further down.
>>> 3) should River use (any) 1.6 specific APIs?
>> I can't think of yet, however we can cross that bridge when we come 
>> to it.
>>> 4) should River depend on any bug fixes present in 1.6 APIs for APIs
>>> which were already defined in 1.5?
>>> Concerning 1) it seems the consensus is yes with no limitations. The
>>> only language change in 1.6 that I'm aware of in 1.6 is that @Override
>>> can be applied to methods that implement an a method defined in an
>>> interface (thus signaling that the method in question must implement a
>>> method defined either in a superclass or a superinterface, or else
>>> won't compile). I suggest we can live without the @Override change for
>>> the time being.
>>> Concerning 2) the natural candidate is at least java.util.concurrent,
>>> but there are other interesting APIs (see
>>> http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html). The main
>>> issue with APIs is that without a backport available, the classes that
>>> depend on 1.4 won't be able to use those classes. I think we need to
>>> settle the 1.4 compatibility issue regarding APIs, and my vote is that
>>> we use 1.5 APIs without restrictions. If we remain compatible with
>>> Jini 2.1 for deployment and access of services (at the level of River
>>> infrastructure), we are covered.
>> This is a very valid issue, I think the best way to handle it is to 
>> not place restrictions on the use of the Java 1.5 api, but instead 
>> use the compatibility table from Retrotranslator 
>> http://retrotranslator.sourceforge.net/ as a guide and on an as 
>> needed basis submit patches to the Retrotranslator project to add 
>> functionality when it makes sense to, when it doesn't, fall back to 
>> the way one might solve the problem with Java 1.4 or if it can be 
>> justified at the time, drop support for Java 1.4.  The River JRE 1.4 
>> compatibility release should be bundled separately so we can quantify 
>> the demand once River is released.
>> I think that it's important to run the integration tests and the unit 
>> tests that the developer creates, against the class files compiled by 
>> Retrotranslator on JRE 1.4, as well as the main build release on Java 
>> 5, this does create an additional level of vailidation, since all 
>> tests are run twice, once againt JRE 5 with the main release 
>> classfiles and a second time with the Retrotranlator generated 
>> classfiles on JRE1.4
>> Maintaining compatibility with the Jini 2.1 specification, are there 
>> any reasons to break this?  What about River-277: Adapt various Jini 
>> specifications/implementation to enable usage over the Internet?
>> What are thoughts?
>>> Concerning 3), I think it's better for the time being if River does
>>> not use 1.6-specific APIs, unless there are delicious candidates
>>> listed in http://java.sun.com/javase/6/webnotes/features.html (I don't
>>> know of any).
>> Well it may be justifyable if for say performance reasons or to 
>> workaround a Java 5 bug, provided that the programmer uses a try 
>> catch clause with  fallback functionality, or checks the platform 
>> before executing the method.  It's ugly, however it may be 
>> justifyable in some circumstances, don't want to rule it out 
>> entirely, its something that can be discussed on the list by the 
>> developer at the time.
>> // Comment explaining why
>> try{
>>          Something.java6Method(String s);
>> } catch (UnsupportedOperationException e) {
>>          // Do something else
>> }
>>> Concerning 4), I think the reality of the current deployed base is
>>> that we will need to write and test against 1.5 JDKs and work around
>>> known bugs which were fixed in 1.6 and not backported.
>> Agree
>>> Regards
>>> Patrick

View raw message