Sometimes breakages are good, especially if they fix hidden runtime bugs
; ) Even if it does cause some pain.
James Grahn wrote:
I'm in the Java 5 camp.
JavaSpace in particular could benefit from using generics, and I
believe the implementation wouldn't break any code. (All casting
from a read or take would just become redundant.)
Well, alright... it wouldn't break any _correct_ code (incorrect casts
wouldn't compile).
James Grahn
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
<[email protected]> 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
