I'm astonished that the Apache Commons Collections project still hasn't got around to making their library generics-aware. I really like the features provided by this library, but the lack of support for generics is a big turn-off. There is a Lavalabs fork of Commons Collections which does support generics, which seems to claim backward compatibility, but when I tried updating to this version, my web application failed to start (in JBoss).
My questions are:
Whether anyone has successfully updated from Commons Collections to the fork mentioned above
If Commons Collections has any plans to add support for generics
BTW, I'm aware of Google collections, but am reluctant to use it until the API stabilises.
Cheers,
Don
Consider Google Collections. From their Javalobby interview:
[Google Collections is] built with Java 5 features: generics, enums, covariant return types, etc. When writing Java 5 code, you want a collections library that takes full advantage of the language. In addition, we put enormous effort into making the library complete, robust, and consistent with the JDK collection classes.
There are contributions. Checkout the jira's
There is also a JDK5 branch.
We do would like to add generics and update Commons Collections to 1.5 (and 1.6). The biggest problem is how to address backwards compatibility. And people have very different opinions there. For some of the Commons components the newer JDK almost asks for a rewrite for the new JDKs IMHO.
During ApacheCon I felt the urge across several people to get this moving though. It's just a big task.
Feel free to show up on dev#commons.apache.org
cheers,
Torsten
Given that the last word in Jakarta's own internal debate was in Dec 07, I would say that Apache will not embrace generics, leaving the field open for something Java5 friendly like Google Collections.
I say, bite the bullet and switch to google-collections, at least for new code.
I know you're concerned about stability, but the google-collections library is VERY close to stable for 1.0 release -- hang out on the dev list or watch their reported issues, they are already very very cautious about changes, especially breaking ones. Any incompatibilities between the current release and the (seemingly imminent) 1.0 final are going to be extremely tiny.
Also, if you're worried about stability, pick a version (e.g. the current one, 1.0 RC4), and... just don't upgrade. Sure, you won't get any new features, but commons-collections hasn't been updated in a meaningful way in several years, so are you really any worse off? At least you're frozen on something with generics and (IMHO) a much better API.
The general BC problem is that package org.apache.commons.collections has been renamed to org.apache.commons.collections15. I don't know the reason of this change. Try to rename it back, recompile the library and run your application again.
I have found this issue using Clirr tool on commons-collections-3.2.1.jar (from Apache) and collections-generic-4.01.jar (from Lavalabs).
I can't imagine what reason you can have to don't use google collections. It's quite simple to use that library.
For my work i use both, apache collections and google collections.
can you explain more about why you can't use google collections?
regards
There's a genericised port of Commons Collections 3.1 available here, which we've been using for a few years now. Does the job nicely, and since it's based strictly on the existing Commons source, it has a stable API.
It could use updating to conform to Commons Collections 3.2, though.
Have a read on the collection blog, it provide the completed understanding of the collection framework.
http://tech.konnectingtheworld.com/2010/09/a-note-on-java-collections/
If you feel that you query has not been answered, get in touch with me. I shall try to provide you the information as much as I can.
Related
Will using deprecated classes cause severe problems to the program?
What is the meaning of deprecated?
Can I still work with deprecated classes?
An example for it is the ProgressDialog view in Android. It deprecated from API 26 and the replacement is the ProgressBar view. What happens if I will still use the ProgressDialog? It is extremely comfortable and exactly what I was aiming for.
From the documentation:
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. Compilers warn when a deprecated program element is used or overridden in non-deprecated code.
So you can use some deprecated methods but it won't be the best practice because there are better alternative exists(but in some cases this can even be dangerous)
Yes and no. You can use them for maintaining old API levels, tacking into account that in newer android versions these classes may be removed. So usually you would wrap its usage in a if/else condition to use them only to maintain such functionality in old Android versions, only when there is no compatible replacement in newer versions.
Google has a bad habit of not maintaining back-compatibility which is an essential best practice in computer science and technology. I appreciate that deprecated means there are better alternatives and the comment "In theory, the deprecated libraries you are using should be supported indefinitely. However, the Google Play Store may at some point not support your API level, which means you might not be able to keep updating your app." is very pertinent. API level should be able to continue supporting those "deprecated" classes. I am very sure many of us can find several examples where so called "deprecated" are much better than their "updated" alternatives.
We use ConcurrentLinkedHashMap from https://code.google.com/p/concurrentlinkedhashmap/ in a project and I saw a note that it was integrated into Guava's MapMaker and CacheBuilder back in 2010. The info is very brief:
Integration of the algorithmic techniques into MapMaker will be released in Google Guava r08 and is heavily based on this version.
What does it mean exactly?
The concurrentlinkedhashmap project seems to be still active.
Was it just a one time integration to bootstrap the Guava cache package?
Have the two projects evolved independently since 2010?
If so, what are the main differences between them today?
What does it mean exactly?
Guava is the long term replacement and most of the time you should use it. The history is that ConcurrentLinkedHashMap figured out the algorithms, Guava subsumed it, and then focused on adding features.
The concurrentlinkedhashmap project seems to be still active.
It has always been a weekend project, so active means that I have a scratch to itch or responded to a change request. It is also easier to experiment in CLHM than Guava, so I tended to prove out ideas there prior us porting them over. My involvement with Guava was as a 20%-er.
Was it just a one time integration to bootstrap the Guava cache package?
Yes. We first overhauled MapMaker and then split out caching into a dedicated API. It is a one-way migration of ideas and improvements into Guava.
Have the two projects evolved independently since 2010?
Both have stayed dedicated to their goals. The motivation behind ConcurrentLinkedHashMap was to figure out how to write a truly concurrent cache without taking shortcuts. The goal behind Guava is to provide a feature rich library with a beautiful API and solid implementation for broad usage.
What are the main differences between them today?
Guava is packed with features and has a full time team at Google supporting it. Use it!
ConcurrentLinkedHashMap has higher absolute concurrency by decorating, instead of forking, ConcurrentHashMap. This allows it to be used with ConcurrentHashMapV8, which is based on a new algorithm. CLHM does not relying on segment locks, which improves write performance and allows for maintaining a single LRU chain. I have an experimental branch with the LIRS policy that I hope to someday finish.
The long term hope is that Doug Lea will one day write a cache inspired by our work and teach us a few things in the process.
Update (3/15): Caffeine is a Java 8 rewrite of Guava's cache. It tries to provide the best of ConcurrentLinkedHashMap and Guava, modernized with Java 8, and adopting the techniques that I've learned since those previous projects.
It seems like every java project I join or start on always has commons-lang as a dependency - and for good reason. commons-lang has tons of classes and utility methods that are pretty standard fair with the most standard APIs in other languages. Why hasn't Sun/Oracle/JCP adopted some of the things in commons-lang in to the standard api?
As pointed out already, some features in the commons API have made it into Java, often implemented (IMHO) better than they were originally in the commons library. Enums is the classic example.
In terms of why they don't adopt more of commons-lang, well with some classes there's the element of confusion. Take StrBuilder for example, it's more powerful than the Java StringBuilder and it's extensible. But I'm not sure I'd be for adding such a class into the Java core API, StringBuilder/StringBuffer are perfectly good enough for most purposes and having another one in there would really just become a bit confusing. They couldn't really alter StringBuilder in a way that would accommodate all of the changes either because that could break existing code. Even if they did add one, what about when someone else came along with another more powerful version? StrBuilder2? Before long everything's a big mess (some argue that the core API is already, let alone with such additions.)
And as always with these things, the big point is what should be included from commons-lang. Some people would probably want to see the MutableXXX classes added, others the XXXUtils classes, others the time package... there isn't really a common consensus.
The other big thing is that the Java developers have to be a lot more careful what goes in the core Java API than the Apache developers do for commons-lang. If a crappy design in commons-lang is superseded in a future release, the old one can be deprecated and subsequently removed (indeed this seems to be what happens.) In the core Java API it needs to stay for backwards compatibility reasons, just causing more clutter.
For what it's worth though I do think more of the functionality in commons-lang should probably be included. I can just see the reasons, at least in part, why it's not.
Historically Apache Commons implemented some of the features that later were introduced in Java 5, such as enums and annotations. Their implementation was sufficiently different to make integration difficult.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was looking for a bidirectional map implementation in Java, and stumbled upon these two libraries:
Google Guava (formerly "Google Collections")
Apache Commons Collections
Both are free, have the bidirectional map implementation that I was looking for (BidiMap in Apache, BiMap in Google), are amazingly nearly the same size (Apache 493 kB, Google 499 kB) [ed.: no longer true!] and seem in all ways pretty similar to me.
Which one should I choose, and why? Are there some other equivalent alternatives (must be free and have at least the bidirectional map)? I'm working with the latest Java SE, so no need to artificially limit to Java 5 or anything like that.
In my opinion the better choice is Guava (formerly known as Google collections):
it's more modern (has generics)
it absolutely follows the Collections API requirements
it's actively maintained
CacheBuilder and it's predecessor MapMaker are just plain awesome
Apache Commons Collections is a good library as well, but it has long failed to provide a generics-enabled version (which is a major drawback for a collections API in my opinion) and generally seems to be in a maintenance/don't-do-too-much-work-on-it mode Recently Commons Collections has picked up some steam again, but it has some catching up to do..
If download size/memory footprint/code size is an issue then Apache Commons Collections might be a better candidate, since it is a common dependency of other libraries. Therefore using it in your own code as well could potentially be done without adding any additional dependencies. Edit: This particular "advantage" has been partially subverted by now, since many new libraries actually depend on Guava and not on Apache Commons Collections.
From the faq:
Google Collections FAQ
Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?
The Apache Commons Collections very clearly did not meet our needs. It
does not use generics, which is a problem for us as we hate to get
compilation warnings from our code. It has also been in a "holding
pattern" for a long time. We could see that it would require a pretty
major investment from us to fix it up until we were happy to use it,
and in the meantime, our own library was already growing organically.
An important difference between the Apache library and ours is that
our collections very faithfully adhere to the contracts specified by
the JDK interfaces they implement. If you review the Apache
documentation, you'll find countless examples of violations. They
deserve credit for pointing these out so clearly, but still, deviating
from standard collection behavior is risky! You must be careful what
you do with such a collection; bugs are always just waiting to happen.
Our collections are fully generified and never violate their contracts
(with isolated exceptions, where JDK implementations have set a strong
precedent for acceptable violations). This means you can pass one of
our collections to any method that expects a Collection and feel
pretty confident that things will work exactly as they should.
The most important things I've found that make Google Collections the place to start:
Generics (Collections without Generics -- FTL)
Consistency with Collections framework (Josh Bloch was a key player in this framework)
Correctness. These guys are desperately tied to getting this problem right; they have something like 25K unit tests, and are tied to getting the API just right.
Here's a great Youtube video of a talk that was given by the primary author and he does a good job of discussing what is worth knowing about this library.
Two other things (I hope I'm not wrong)
The licence of Guava (new name for google collections) is the Apache License 2.0, meaning: the same one as for Apache Commons project
I cannot find the source code of Guava in a file to download (it seems only a git-access is possible)
One nasty thing about Guava is that Multimap does not extend java.util.Map. If You have Your own methods that work on Maps they won't work on Guava Multimaps (Apache MultiMap interface does extend java.util.Map). I'm sure that there's some good reason why it's the way it's but it's also inconvenient.
I've used ServiceWrapper a few times in the past, however, the dual license is somewhat complex for commercial products (generally you have to pay them). Are there are fully FOSS alternatives with similar functionality?
YAJSW seems to be the best alternative, though I have not yet completed my evaluation.
Try Apache Procrun. It's what Tomcat uses on Windows. There is also Apache jsvc for Unix; they are both part of a parent project called Apache Commons Daemon.
Which functionality do you need exactly?
In their table I didn't see anything non-trivial. But it would help if you narrow down your requirements.
We use the open source JavaService package.
Edit: We use an older version of this package (when it was being maintained by the original developer, Alexandria Software Consulting). I have not had a chance to look at the improvements made since then.