[jdom-interest] JDOM not using raw typing
jdom at stolsvik.com
Wed Mar 28 04:57:12 PST 2007
Victor Toni wrote:
> Hielke Hoeve wrote:
>> On 28/03/07, Endre Stølsvik <jdom at stolsvik.com> wrote:
>>> Jason Hunter wrote:
>>> Also, one could use org.jdom2 as package name for the 1.5 version,
>>> although obviously utterly loosing compatibility between code coded
>>> against v1 and other code coded against v2 - but I think even this could
>>> be handled using a simple "converter" between a v1 DOM and a v2 DOM, or
>>> the other way.
> Have you tried one of these?
> I guess not because they won't work.
>> javac -source=1.5 -target=1.3
>> javac -source=1.5 -target=1.4
> The only option left is the undocumented -target jsr14 which is not
You're absolutely right.
However, the target=jsr14 switch was actually exactly what I was after
(although I hoped the result was for java 1.3, and not 1.4).
Article from Brian Goetz, 27. feb 2007:
It mentions this switch, and retroweaver and retrotranslater:
During the development of the Java generics specification (and other
language features added in Java 5), experimental support was added to
the javac compiler to allow it to consume Java 5 language features and
generate bytecode that could be run on a Java 1.4 JVM. While these
features are not supported (or even documented), they are used by a
number of open source projects to allow developers to code using Java 5
language features and produce JAR files that can be used on earlier
JVMs. And, now that javac is open source, it is possible the features
might be supported by a third party. To activate these features, you can
invoke javac with the -source 1.5 and -target jsr14 options.
The JSR 14 target mode of javac causes the compiler to emit JDK
1.4-compatible bytecode corresponding to Java 5 language features:
* Generics and varargs: The casts inserted by the compiler in the
presence of generics have no dependency on the class library, and so
they can execute equally well on a pre-5 JVM. Similarly, the code
generated by the compiler in the presence of variable-length argument
lists has no dependency on the class library.
* for-each loop: ...
* Autoboxing: ...
* String concatenation: ...
* Enumerations: The JSR 14 target mode of javac has no special
support for enumerations. Code that attempts to use enumerations will
fail with a NoClassDefFoundError looking for the java.lang.Enum base class.
Using the JSR 14 target mode allows you to write code that uses
generics, autoboxing, and the for-each loop in the "easy" cases, which
may suffice for many projects. It is convenient, if unsupported, and the
compiler generates mostly compatible bytecode in a single pass. "
.. But really, the thing needed here is not to develop jdom in java 1.5,
only that client 1.5 code will compile cleanly ("generically") with
jdom, and at the same time be runtime compatible with earlier JVMs and code.
I tried to add these to the ant file, using javac 1.6.0-b105, and it
didn't complain (as it did with "-source=1.5 -target=1.5"), so the
switch apparently still works.
(One gets some funny varargs warnings when compiling jdom on 1.6, so
I guess the ant-file should have "-source=1.3 -target=1.3" (which
actually gives a warning-free result), also to get the resulting jar to
run on a pre-current-javac JVM)
More information about the jdom-interest