[concurrency-interest] Why not J2SE 5?
Osvaldo Pinali Doederlein
Mon, 06 Dec 2004 13:27:26 -0300
David Holmes wrote:
>>I wish jdk1.5 had the option of compiling into at least jdk1.4 byte
>>code. So even though production systems still need to stay with 1.4,
>>development can start moving to 1.5.
> It does! Use the -source and -target options on javac eg:
> javac -target 1.4 -source 1.4 Foo.java
No it doesn't work. This produces the following output:
"javac: source release 1.5 requires target release 1.5"
This is a feature I tried (I and many others I'm sure) to lobby Sun to
have in Tiger. Early alpha builds accepted this combination of flags,
even if not perfectly, for example autoboxing would be compiled with
dependencies on new 5.0 APIs; I reported this as a bug (4975921) only
to learn that Tiger wasn't planned to support this at all. I guess
Sun didn't want to create a dialect somewhere btw 1.4 and 1.5, because
it's impossible to compile all of the new language features to bytecode
compatible with 1.4 VMs (some features, like enums and annotations,
depend on new core APIs and some changes in the VM and runtime libs,
like the serialization changes to support enums).
There's a guy who created a weaver, http://retroweaver.sourceforge.net/,
that translates bytecode compiled with "-target 1.5" to 1.4-compatible
bytecode (that may depend on an extension library), but it's not a 100%
compatible and seamless; you will get in trouble with those hard issues
like on-the-wire serialized enum interoperability or reflection details.
But wait. javac supports "-source 1.5 -target jsr14" where "jsr14" is
unsupported, I thought this would enables supports only for generics and
related features (like covariance), like JSR14's Early Access compilers.
But I tested this now, and it seems to support all of the new language
(even fixes bug 4975921, which Sun marked "Closed, will not be fixed"!
it compiles "Object x = 10" to "Integer x = new Integer(10)", using the
Integer(int) constructor, not the 5.0-specific Integer.valueOf(int)!!)
I wonder if this works well enough (at least for features not demanding
core changes) so I don't need tools like RetroWeaver. Too bad it's not
supported, anyway. It doesn't attempt to solve these problems, e.g. it
accept enums and produces code that won't work in J2SE1.4 due to the
missing java.lang.Enum class. I wish "-target jsr14" would work in
these cases, but emit a warning about compiler-introduced dependencies
on classes and methods available only on 5.0.
Osvaldo Pinali Doederlein Visionnaire Informática S/A
Arquiteto de Tecnologia +55 (41) 337-1000 #223