commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: Commons-Collections enhanced with Java Generics Support
Date Wed, 25 May 2005 22:17:16 GMT
Stephen,

Maybe we could call it Commons Generics?  Just a thought.  But, that might
leave a door open to put non-collection classes in there, as generics can be
any type of parameterized class.  Anyway, how should we proceed from here
(regardless of what we call it)?  Maybe a new project in Jakarta Commons
would be in order.  Wouldn't this situation be analogous to the Xerces Java
2 vs. Xerces Java 1 situation?  They created a new project for their "next
generation."  Shouldn't we?  They kept the same package structure, from what
I can tell (org.apache.xerces).  Do you think we could do the same and let
folks upgrade to the next generation without having to change their code?  I
don't know much about the binary compatibility issue.  Would they just have
to recompile their classes using a JDK5 compiler against the new classes?
Of course, they'd get those new warning messages, but at least the code
would work.  Right?

James

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Tuesday, May 24, 2005 6:56 PM
To: Jakarta Commons Developers List
Subject: Re: Commons-Collections enhanced with Java Generics Support

John Watkinson wrote:
> We are definitely ready and willing to 
> bring the code back in to the Jakarta Commons when the time is right. 
> Our goal was to get it done so that developers (us included) could start 
> using and improving it, but we hope that we can eventually contribute it 
> all back to the Commons.
+1, This sounds like the right approach to me.

> 1) Should it be a separate project or a branch of Commons-Collections?
> 
> It is the case that Java 1.5 classes are NOT binary compatible with 
> previous runtime environments (1.4 and earlier). So, the original 
> Collections have a very long life ahead of them. Also, an enormous 
> number of third-party libraries have the Commons-Collections as a 
> dependency and it will not be possible to ensure binary compatibility 
> between the generic-enabled Commons-Collections and the original 
> library, even if the code is run on the 1.5 platform.
There are numerous good points here. [collections] got a bad name with 
the 3.0 release for breaking binary compatability. (In fact this was 99% 
FUD spread by Hani and TSS, because only a couple of constants were 
incompatible).

However, what it does serve to emphasise is that [collections] must not 
only be 'clean', but also be perceived to be clean. To me, this means 
that clever tools like Retroweaver would not be an option.

> 2) Is there enough support for the 1.5 Collections to warrant a new 
> project?
> 
> I agree with the points raised earlier on this topic. Developers may not 
> yet be clamoring for this, but as more of them adopt 1.5, they may begin 
> doing so. Also, a high-profile project like the Commons-Collections 
> could help attract developers to 1.5.
The main problem is keeping bug fixes in sync between the two codebases. 
However, a separate package structure is the only practical solution to 
achieve 1.5 collections. Whether it is a separate project is a moot 
point, and I don't have a strong view either way.

I would expect the package name for collections JDK1.5 to be
  org.apache.commons.collections15

> 3) What are the open-source credentials of Matt Hall and John Watkinson?
> 
> We are the authors of Streamsicle (http://www.streamsicle.com). I have 
> also written SwarmCache (http://swarmcache.sourceforge.net) and MegaMap 
> (http://megamap.sourceforge.net). We are the authors of Starfish, a 
> project that we are in the process of opening 
> (http://www.larvalabs.com/starfish).
Having previous OSS experience will be helpful.

Finally, any ideas from http://collections15.sourceforge.net should also 
be taken into account.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message