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
