The following is an excerpt from a Thesis by Tamara Steijger:
"Downgrading Java 5.0 Projects
An approach based on source-code
transformations"
Tamara Steijger
Oct
2008
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.
Cheers,
Peter.
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
