[jdom-interest] JDOM not using raw typing

[Endre Stølsvik]

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 
> recommended.

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:
http://www-128.ibm.com/developerworks/java/library/j-jtp02277.html

It mentions this switch, and retroweaver and retrotranslater:

   "JSR 14

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)


Regards,
Endre.