Jakarta Team Releases Commons Collections 3.0

Discussions

News: Jakarta Team Releases Commons Collections 3.0

  1. Jakarta Team Releases Commons Collections 3.0 (19 messages)

    The Commons Collections team is pleased to announce that the Commons Collections 3.0 release is now available.

    Commons Collections is a library providing implementations, interfaces and utilities enhancing the Java Collections Framework.

    This is a major release. If you are upgrading, please read the release notes for more information.

    "Commons-Collections was originally created as a place to share collection implementations created in various places around Jakarta. As a result, there was no clear design or structure to the component. As from this 3.0 release, that changes with a clear, consistent package structure being used

    As a result of the new structure, several classes have moved packages. When moving from a previous release to this one it is important to check all your code. Some implementations that were moved were also optimised, and may contain API changes.

    In addition to the new package structure, it was determined that collections was getting too large. As a result, two new code donations - primitive collections and event notification collections - have been separated into their own projects within commons. Primitives has already released a version 1.0, while Events resides in the sandbox at present."


    Commons Collections Home page

    Downloads: Binary, Source

    JavaDoc

    Do people find themselves with lib/ directories of these jakarta-* jars, as well as other small open source libraries?

    Threaded Messages (19)

  2. To much common jars?[ Go to top ]

    Do people find themselves with lib/ directories of these jakarta-* jars, as well >as other small open source libraries?


    Definitely. Slowly but surely I am getting a bad feeling on this, I have met some situations allready were it was really ugly to resolve the various dependencys on different versions of utility jars (not only jakarta-commons, but this is a classic)
  3. To much common jars?[ Go to top ]

    Definitely. Slowly but surely I am getting a bad feeling on this


    Agreed.. kind of. I have no problem including tons of jars, but having to worry about dependencies is becoming a problem. As smaller 3rd party (mainly open source) libraries and frameworks get more and more popular, this is really going to become a problem as these projects change and mature. What happens when Stuts and Hibernate rely on different versions of Commons-Collections?
  4. Backward compatibility...[ Go to top ]

    What happens when Stuts and Hibernate rely on different versions of Commons-Collections?


    This seems like a big issue with Commons Collections 3.0. It moves classes between packages without providing for backward compatibility. This means *all* code has to move to Collections 3.0 at the same time. This is going to be difficult to handle.
  5. Serves you right[ Go to top ]

    Easy, you get bitten, and hopefully learn your lesson and stop relying on pointless libraries that break binary compatibility with every release.

    Survival of the fittest, the unfit almost never know they're unfit.
  6. Are you suggesting that the best path is to roll your own version of all of the functionality you need in some of these projects? I certainly have no desire to roll my own version of a lot of the things in the jakarta commons, such as DB connector. There is certainly some value to be found in commons collections, lang, and HttpClient.

    One big problem is the ridiculous release strategy. Commons collections went almost a year and half after 2.1, before releasing 3.0. In between that, they did not have one single bug fix release.

    It appears the jakarta people want to make it as hard as possible to use their stuff. The only people they care to serve are themselves and their desires. With them it appears to always be refactoring over releasing.
  7. Are you suggesting that the best path is to roll your own version of all of the functionality you need in some of these projects? I certainly have no desire to roll my own version of a lot of the things in the jakarta commons, such as DB connector. There is certainly some value to be found in commons collections, lang, and HttpClient.

    >
    If they can't maintain backwards compatibility between releases then yes, that's indeed the only way forward.
    I use Tomcat 4.1.21, Taglibs Standard 1.0.4, Xerces 2.6.0, and Xalan 2.5.2 (at the moment that's it, not counting Ant and JUnit.
    What if one of these depends on commons-collections 2, another on common-collections 3 (in this case that's no problem but when one changes...)?
    Conflict...
    Can't have that, it basically locks users of several other products into specific versions of those until all have been updated to use the new "common" libraries AND you have updated your own work as well.
    The first I can live with (if there isn't a compelling reason to move to the latest and greatest I usually don't during the lifetime of at least a major release cycle), the second I'd like to keep under control myself.

    > It appears the jakarta people want to make it as hard as possible to use their stuff. The only people they care to serve are themselves and their desires. With them it appears to always be refactoring over releasing.

    Don't blame them. I like tinkering as much as the next guy and these are people doing it for fun not money...
    But it can indeed be frustrating from time to time.
    Still remember when Xerces 2 was released, had to rewrite a lot of code that made use of functions and classes that suddenly no longer existed.
  8. Good Question.[ Go to top ]

    What happens when Stuts and Hibernate rely on different versions of Commons-Collections? <


    Very Good Question.

    How backward-compatible is collections 3.0? We had to kick out commons-lang because the latest release was not completely backward compatible. Will we have to do the same thing with commons-collections?

    I'm turning real cold on these Jakarta libraries - seems like they should be kept for internal Jakarta-use-only perhaps.

    Looking for advice on this...

    Gavin
  9. Simple[ Go to top ]

    The problem is with the package name.
    They need to rename all packages to org.apache.commons.collections3.blah (note the number 3 in collections), and ready.

    Simple.
  10. Good Question.[ Go to top ]


    > Looking for advice on this...
    >
    Not much of an advise, but if I really need them I would probably move the required classes to my own package, given the existing refactoring tools a matter of seconds. Even newer releases should be easy to integrate, and none will ever complain about version clashes with your tool.

    Jens
  11. To much common jars?[ Go to top ]

    Agree - especially with packages like collections and beanutils being so standard, it creates a lot of resistance to pulling down a project and giving it a quick trial run. I appreciate the Spring approach - one version with all dependencies and one without. At the very least, it would be useful if projects released with a list of URLs for the JARs (either online or in the installation notes).

    Still, it makes me wonder if there's a need for a project like the linux dependency managers, which would go and fetch all the jars you need. That would make a sweet Ant task. I haven't seen anything like that, though I recall the perl CPAN module can handle it. The problem is there's no protocol for specifying version dependencies in JAR files.
  12. To much common jars?[ Go to top ]

    Michael: Still, it makes me wonder if there's a need for a project like the linux dependency managers, which would go and fetch all the jars you need.

    Ah, you want Maven ;-)
  13. Commons-collections[ Go to top ]

    I appreciate what jakarta-commons stands for, but I also agree there are some open issues here...

    - Will upgrading to Collections 3.0 break current versions of BeanUtils, Digester, or other jakarta libs that depend on collections?

    - In general the javadocs are non-existant to pretty bad. This would be one area for nice improvement over moving classes around every release...

    I for one use jakarta-lang fairly extensively myself, and was lucky to adopt post 2.0. I only use a bit of the functionality from collections, so I'm more concerned about it completely breaking other packages I do use more often.

    I agree that little regard for your existing user base is a good way to find yourself with no users. I mean, for example, I can't imagine jakarta taking the "Validate" class out of lang and moving it somewhere else, completely breaking just about every one of my classes... But how the heck do I know they won't do that...

    I guess it's a tradeoff...the continual design rule of thumb is to isolate your 3rdparty dependencies...well another rule of thumb is to keep the codebase you have to support and test small, and jakarta-commons greatly helps with this... however, it would be nice if I knew their developers are considerate of the investment existing users have made in their projects.
  14. Results[ Go to top ]

    FYI: I was able to plug collections 3 into my codebase and the existing jakarta libs continued to function as expected. Turns out I didn't have to recompile anything since the code I used (mainly the comparator stuff) was left unchanged.

    Obviously this is just with my codebase and the results might be completely different for someone else.
  15. Sorry to be so dumb, but if all of the packages in 3.0 are named common3.*, what's the big deal?

    Say Struts and Hibernate are using different versions of Commons. I put both 2.1 and 3.0 in my class path. There are no namespace collisions, so the 2.1 dependencies bind to the 2.1 code, and the 3.0 dependencies bind to the 3.0 code.

    Sure, all things being equal, I'd prefer not to put two different revs of the same library in my classpath, but this is hardly a Nazi atrocity.
  16. Sorry to be so dumb, but if all of the packages in 3.0 are named common3.*, what's the big deal? <<<


    Unfortunately, they have not been renamed.


    http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/index.html
  17. Unfortunately, they have not been renamed.

    Dude, that is pretty weak.
  18. Making decisions[ Go to top ]

    I thought I'd take the opportunity to respond to some comments posted here as one of the key developers on Commons Collections.

    1) Collections 3.0 IS backwardsly compatable with 2.1. Classes which have moved packages retain the original version as deprecated in the release jar.

    2) The length of time between Collections 2.1 and 3.0 is unfortunate. Always remember however that we volunteer to do this, and we are just a very few people.

    3) The approach on both Collections and Lang over the past 2-3 years has been to fix the mistakes of previous versions and get them sorted for the future. Many people complain that the JDK hasn't got rid of its junk (like java util Date). We have chosen to progress, not stand still.


    It comes down to making decisions. We choose to move forward and not lock ourselves to past mistakes. But we choose to do it in a backwards compatible way via deprecation. Hopefully on closer examination you'll understand why the change really had to happen (eg. the comparators and iterators moved package in an earlier collections version, too many classes for one package) and why there shouldn't need to be a change of this magnitude again in collections.

    And besides, there's a ton of stuff in this release which is new and interesting which no-ones commented on yet like MapIterator or BidiMap ;-)
  19. Thank you Jakarta![ Go to top ]

    Stephen. Your guy's efforts are greatly appreciated! I (and my entire company) LOVE your guy's stuff. Pay no attention to the reactionary rifraff ;-) They post on emotion without bothering to look into the details.

    Cheers and keep up the good work.
  20. All that is good to hear[ Go to top ]

    We appreciate what jakarta stands for and the help you guys have been in our projects to-date. I think this just illustrates how useful the software is and also how many people are invested in it (which leads to valid concerns like these.)