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 00:29:34 GMT
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
>
>   

Mime
View raw message