> 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. This could result > in some misery if a programmer requires libraries that depend on both > versions. So, this suggests to me that the generics-enabled > Commons-Collections should be a new project with a different package > structure than the original.
Mhmm, I'm not sure why missing binary compatibility makes it necessary to create a different package structure let alone a different project ? Shouldn't it suffice to create two jars, one for pre-1.5 and one for 1.5 and above ? Depending on which Java version the user employs, he then chooses one of these jars. This even ensures drop-in compatibility for people that already use commons-collections with Java 5. And branching or a different project means maintaining two APIs in parallel ... > 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. +1, especially if enough gaps are filled (like with the 'old' commons-collections). Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
