[jdom-interest] JDOM not using raw typing

[Endre Stølsvik]

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.
> 
> Would be better to use the
> javac -source=1.5 -target=1.3
> javac -source=1.5 -target=1.4
> javac -source=1.5 -target=1.5
> 
> options to create bin jar files for each java version. Then you'd have
> 1 branch in cvs, more groups on the downloads page but less people
> having to mess with merging branches all the time.

The type information of generics is "erased" - it is only stored in some 
auxiliary fields in the class files (for compilers and IDEs, I presume), 
not used at runtime. I'm not sure if "target=1.3" will include this info 
- but in any case, the "target=1.4" is not necessary at all (as the 1.3 
version would be 100% just as good). If the generics-info is present in 
the 1.3 version (when compiled on a >= 1.5 using "-source=1.5 
-target=1.3"), as I currently believe (!), this will be the one and only 
version needed, and everything would be perfect.

Java Generics and Collections: Evolution, Not Revolution -
   Part 1, Page 1:
http://www.onjava.com/pub/a/onjava/excerpt/javagenerics_chap05/index.html

   " Java implements generics via erasure, which ensures that legacy and 
generic versions usually generate identical class files, save for some 
auxiliary information about types. It is possible to replace a legacy 
class file by a generic class file without changing, or even 
recompiling, any client code; this is called binary compatibility.

We summarize this with the motto binary compatibility ensures migration 
compatibility—or, more concisely, erasure eases evolution.

This section shows how to add generics to existing code; it considers a 
small example, a library for stacks that extends the Collections 
Framework, together with an associated client. We begin with the legacy 
stack library and client (written for Java before generics), and then 
present the corresponding generic library and client (written for Java 
with generics). Our example code is small, so it is easy to update to 
generics all in one go, but in practice the library and client will be 
much larger, and we may want to evolve them separately. This is aided by 
raw types, which are the legacy counterpart of parameterized types."


Java Generics and Collections: Evolution, Not Revolution -
   Part 2, Page 2:
http://www.onjava.com/pub/a/excerpt/javagenerics_chap05/index1.html?page=2

   " In such cases, it makes sense to update the library to use 
parameterized types in its method signatures, but not to change the 
method bodies. There are three ways to do this: by making minimal 
changes to the source, by creating stub files, or by use of wrappers. We 
recommend use of minimal changes when you have access to source and use 
of stubs when you have access only to class files, and we recommend 
against use of wrappers. "

...

   " To review, we have seen both generic and legacy versions of a 
library and client. These generate equivalent class files, which greatly 
eases evolution. You can use a generic library with a legacy client, or 
a legacy library with a generic client. In the latter case, you can 
update the legacy library with generic method signatures, either by 
minimal changes to the source or by use of stub files.

The foundation stone that supports all this is the decision to implement 
generics by erasure, so that generic code generates essentially the same 
class files as legacy code—a property referred to as binary 
compatibility. Usually, adding generics in a natural way causes the 
legacy and generic versions to be binary compatible. However, there are 
some corner cases where caution is required; these are discussed in 
Section 8.4. "

Regards,
Endre