Greg Trasuk wrote:
Just to be specific, I am NOT advocating any wholesale changes to the
net.jini.* APIs to embrace Java 5 features. I simply believe that at
some point it is reasonable to say "Jini requires a Java 5-capable
virtual machine" and as such, allow new APIs and code updates to use
Java 5 features.
I haven't seen anybody suggest changing the API, however if we did we
would need to make sure it was backward compatible similar to the way
Sun implemented Collections, as client code would break without being
rewritten even on Java 5.
As a side issue, EOL or not, Java 1.4 virtual machines are common in
industry (e.g older versions of Websphere, etc), so many projects
currently hold back from making the above assertion. This may or may
not be an issue for Jini.
That's the problem I'd like to mitigate with Retrotranslator. Eg A
client developer may not have the luxury to use JavaSE 5, there might be
a company policy to use Java SE 1.4.2 for whatever reason. A have your
cake and eat it too moment, although I wouldn't call it a free lunch ;)
If we have a separate download for River-X.X-J2SE1.4.zip, available over
time, monitor the downloads, then we'll know what percentage of our
client base is using 1.4
Looking at the Issues on Jira, I think some of these are going to be
easier to solve using Java 5.
Cheers,
Peter.
Cheers,
Greg Trasuk.
On Sun, 2009-03-29 at 20:59, Peter Firmstone wrote:
There's strong support for migrating to Java 5:
Jukka Zitting has proposed we migrate when renaming com.sun.* packages
to org.apache.river.* (River-261)
What release should this be planned for, AR3?
Summary so far (Please correct me if I'm wrong):
Support for Java 5:
Dennis Reedy
Jim Waldo
Jonathan Costers
Greg Trasuk
Niclas Hedhman
Dan Roller
Greg Wonderly
Jukka Zitting
Sean Landis
Peter Firmstone
Additional support for Java 1.4 bytecode (not source) is possible with
Retrotranslator at build time (I'm happy to implement Retrotranslator in
the build scripts). There would be a separate Java 1.4 bytecode release
created at build time from the Java 5 class files after compiling with
JDK 1.5 or later. The separate installation / download for Java 1.4
would allow us to asses remaining demand for Java 1.4. Is anyone
against this?
Are there any remaining concerns about dropping Source level support for
Java 1.4?
Small devices can take advantage of the Surrogate architecture approach
in future (seems to be a consensus among those on the list).
Cheers,
Peter Firmstone.
Jukka Zitting wrote:
Hi,
On Fri, Mar 27, 2009 at 5:33 PM, Patrick Wright <pdoubl...@gmail.com> wrote:
Perhaps the community can make a project-level statement like, "as of
release X, River will begin to use Java 1.5 (or 6) APIs and language
features."
My proposal is that we switch to Java 5 as soon as we rename all the
packages to org.apache.river.
BR,
Jukka Zitting
