[jdom-interest] & in namespace

[Victor Toni]

Jason Hunter wrote:
>> I would suggest first a 1.0.1 bug-fix release to keep compatibility 
>> for older projects. Based on this release JDOM could be migrated to 
>> use generics for a 2.0 release. One could assume that until this task 
>> is complete many more migrations to "Tiger" would have happened.
>> Basically this is more of a management issue for which I would 
>> identify two options:
>> a) keep two branches: "classic" and "generic" and apply changes when 
>> appropriate to both
>> b) updates happen only in the "generic" tree, a tool such as 
>> Retroweaver (http://retroweaver.sourceforge.net/) could be used to 
>> make it available for older Java version.
>>
>> I am really looking forward to have generics in JDOM and would even 
>> step forward for this task ;-)
>>
>> Victor
>
> Considering we're in maintenance mode, it wouldn't be too onerous to 
> just maintain two branches.  However, I'm not actually worried about 
> *my* pain so much as each user's.  If we use the same package name for 
> the Generics version as we have now, isn't that a recipe for DLL hell? 
> Two completely incompatible versions masquerading as the same thing.
>
> Which is why, in a post a while ago, I wondered if the answer was to 
> do org.jdom5 packaging or something like that.
>
> -jh-
There are examples which show the contrary, e.g. the Collections API (I 
know it's bundled with the runtime and this makes a big difference ;-)

If one tries to use a 1.5 version in 1.4 he would get a 
"java.lang.UnsupportedClassVersionError". The other way around is 
trickier because indeed the two jars may "mask" each other but this 
could happen also on updates (e.g. from 1.0 to 1.0.1or 1.1).
That's a downside of Java that one does not have some kind of versioning 
(maybe an additional class org.jdom.Version would be useful but it 
wouldn't prevent "masking") but hey it's no rocket science and it's a 
mistake you make only once ;-)
Having the the same naming  would ease transition if not much of the API 
changes because people may use it as a drop-in replacement and just look 
for the unnecessary casts or verbose loops.
Having a Generics version doesn't need to change the way people use the 
API right now but this depends very much on the implementation details.

Victor