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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
This post was edited and submitted for review last year and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
Is there a Java Logging Library from Google?
I have been using the Google Guava library and find it much more usable than Apache Commons for argument validation (i.e. checking preconditions, invariant object state, conveniently throwing the right Exception type on null, empty String, inlining null checks with assignments, Exception message formatting and specialised typing of nullable types). I have not looked at other features of the library but this was enough for me to switch.
Now the very natural question:
I am doing my logging using Apache Commons Logging, as I was doing for argument validation. Is there a similar "this goes to 11" of the framework from Google that I could switch to, with compound benefits? I don't mind either Log4j or Commons but Guava is so much better than Commons in the aspects I have studied...
I see Android has its logging framework, which I like, does Google offer one for basic Java too?
EDIT: Re-reading my question I realise it may somehow hint to a dogmatic preference for Google code, which I do not have, and an underlying assumption that anything that comes out of Google will be by definition "perfect". I do not hold these "positive preconceptions" at all, what I meant but failed to convey in writing, is that there may be some synergies in adopting a single provider for the two layers. There may be something that intelligently logs, for example, a Guava Optional object or associated object, saving time in constructing specific String.format()s. I was looking for a Google library to leverage these potential synergies not out of a priori preference. I did, in fact, first compare Guava to my old Commons-based way of argument checking before deciding to switch. All things considered, I do appreciate very much the code Google releases for free and I think I have learnt a lot from it and will continue to do so, given its very high quality. I never allowed this to become a cult, though.
References:
Apache Commons Logging
Google Guava
Commons Logging is best avoided. See http://articles.qos.ch/thinkAgain.html for a thorough analysis. Yes, it's very old (and yes, author has a vested interest) but it all applies. The linked 'Commons Logging was my fault' illustrates - there is really not much love for this library - anywhere.
Apparently, Google's preferred solution is java.util.logging. You will see this if you do Java programming on Google App Engine.
The best standard is slf4j over logback. There is no reason to avoid it I think. You will quite possibly be using slf4j already - if not directly then indirectly via other libraries on your classpath - it is the de facto modern standard.
Not that I know of. I recommend using slf4j.
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 14 years ago.
I have heard this a lot, the the Java API is poorly designed. Do you agree and if so, how? I know there are major issues with the Calendar/Date apis. The collections api takes a lot of boilerplate code to use. The File/IO API can be complicated for some things.
But, does this apply across the aboard? And to which versions of Java?
In short, Java APIs are OK.
Longer answer is that some APIs went through changes, sometimes significant, over Java releases and may contain odd pieces. Date, for instance, has quite a few deprecated methods. Nevertheless, what's important is that those API do exist. Java is strong with it's standard library where you can find API for almost anything (may be not always perfect API, but good enough).
P.S. Next time someone produces such a statement, ask him how many languages he designed himself in his life.
Java was not a poorly designed API. Java was made at a time when current best practices weren't exactly known. A lot of implementations were done in a way that are now frowned upon. Since that time there has been a LOT of work done in order to incorporate better techniques and practices. That is why there is a lot of deprecated code.
A bunch of this stuff is talked about in the AMAZING book Effective Java. Bloch talks about some of the "mistakes" that were made in the initial implementation and how they have worked at trying to fix them. If you are a serious Java developer and haven't checked out Effective Java I recommend it HIGHLY. (I actually recommend all of 3 of Bloch's books. He is an excellent writer with a thorough understanding of Java.)
Some of the "is the Java API bad" is covered in the book Effective Java.
There are some parts of the API, like java.util.Date that clearly are poorly designed (all but a couple of methods are deprecated as of JDK 1.1).
There are some other things, such as the lack of interfaces on some of the JDK 1.0 classes (which happened because there were no such thing as interfaces when they were created (interfaces were added before 1.0 but after 0.0).
There are some things that were not done "right" because the convention came after JDK 1.1 has a number of things in the AWT change due to JavaBeans and the naming conventions used).
There are some other things that were not possible before language changes such as enums and generics.
A lot of the API is good. Some of it is poor. The early stuff in JDK 1.0 was clearly written for HotJava (an all Java web browser) and was not really thought out for general consumption.
It is safe to say that the older the API the "poorer" it is. Newer APIs are designed with the knowledge of what came before it. That goes across langauges too - Java is (depending on your opinion) better than C++. C++ is (depending on your opinion) better than C, etc..
Java is old (it has its origins in the early 90s although it wasn't released to 1.0 until 1995 or so) and anything that old has APIs you can criticize. It's not that they're bad per se. They're simply a product of their time and that philosophy is now considered bad (usually with good reason but not always).
To address the ones you bring up:
Date is awful just because it's mutable. An immutable date class would be much cleaner (Calendar has the same problem);
A public constructor on String is, at best, problematic. There's some disagreement on whether or not this is even a problem. In my opinion it is but it's not a massive problem by any stretch;
The java.io.* classes remind me a little of the C++ iostream library in the sense that they were an experiment that I think history has shown to be not a success (if not a failure). Just look at the code you have to write to read a text file into a String. Most other languages have a standard call that'll do this.
And some others:
The pre-1.2 collections are problematic. Josh Bloch (of Effective Java fame) was the architect for the changes to the Java Collections framework in 1.2. It was a massive change for the good and include interfaces for all the classes, abstract implementations, etc;
java.util.Properties extends Hashtable. This is a classic example of a product of its time. In the 90s object frameworks tended to inherit from something. Nowadays the tendency is (rightly) composition over inheritance but that wasn't the case 10-15 years ago.
You could argue that it is "poorly designed" because if they had to do it over now, its authors would build it differently. However, they have made a laudable effort over the years trying to make the best of it. However, hindsight is 20/20.
The Java API has the same problem of any library that has to "evolve while running".
It had been so many years since Java first came out, and many design decisions on the language and the library have evolved. However, the need to be backward-compatible keeps constraining the API and changes to it.
There are many specific examples of usability issues (I've been studying them for the past few years), but then again, few APIs are perfect.
I wouldn't say all of it is poorly designed. The main problem is backward compatibility, people still expect features that have long become deprecated to be available so there code written 10 years ago won't have to be changed. This makes the API rather large and often allows multiple ways to do the same thing with out it being clear which one is better.
Is the Java API poorly designed and why?
No
Because, although it is not perfect, the amount of bad API's if way lot less than the part that is just great!
Anyway, you really should ask this, to whom you heard it from directly, otherwise it will be what in my country is called "Broken telephone" ( which otherwise is a great kids game :)) where each node in the chain of massages modifies the message subtlety and at the end something like:
I don't like java.util.Calendar
may end up to
Java API is completely broken and the desingner should be jailed.
Of course in the middle there's a "message transformation"!!!
:)
Like anything that is around for some time, it gets stale. As with .NET, Sun, et al, have tried to keep things new. But, time stagnates everything, especially considering you cannot change interfaces, only add, as changes break things. :-)
No, Java API is great for most parts, but some parts of it are just rotten. Everyone uses Date and Calendar as examples (here's the mandatory joda-time link) but I'd use XML API (the native/W3C one that is since there's several nowadays) as a good example too: The issue with that part of the whole API is that it just doesn't work as expected and doesn't conform to the rest of the API.
Also one important factor with Java API is that it's consistent and not just within itself but within versions and platforms (with the exception of AWT) and I sure haven't hit any magical spot with Java API yet which would've changed/broken something when doing a version switch.
I started using the Java API in ~1995. Any API which is that old is easy to criticize.
To answer the question of Why:
Java introduced enums too late - the API would be much better if it had enums from the beginning.
WORA (Write Once, Run Everywhere) - or as some say "Write Once, Debug Everywhere". It is incredibly difficult to make a great API when your target is the least common demoninator. No "real" Windows or Mac or Unix or Linux developer can ever be happy with Java.
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 9 years ago.
Anyone working on the Android ('gPhone') have or know of a place where I can find a good ORM tool for it? The code is written in Java, and the database is SQLite. What I would like to find is a tool that given the object definition, can auto-generate the tables and the CRUD functions (that would be awesome), or, barring that, a tool that can take the table definition, the object definition, and auto-generate the CRUD functionality. The rub is that all of this must happen within the Android framework, which has its own conventions as to how database access works.
Thought I'd just add my $0.02 here about my ORMLite package.
It is a lightweight replacement to Hibernate and uses native Android OS database calls to support SQLite on Android. It also supports many other database types using JDBC on other architectures. We have an Android mailing list for ORMLite questions.
This question cannot age but the suggested frameworks can. So, here is first a list of what I find important in such frameworks for comparison:
Is there a Maven or Gradle artifact? (that's a big plus depending on whether you use maven or gradle, obviously)
Is the code accessible in an easy way including a fast overview on commits to judge the activity? (code hosted on github is a definite plus for me, in that matter)
Release management: are there releases/release tags and artifacts for it? (there are some that are hosted on github and require either git clone or offer the master tarball for download - for me a big minus if not even release tags are set and addressed in the README)
as size matters I put up some hints where it was easy to get by (I did not download anything, so from those projects that offer no release artifacts there are no sizes)
And here is a list of frameworks with notes on the points above. I looked up some more like aBatis and Hadi but I added only those that had some activity after 2011.
http://ormlite.com, Maven artifact, 52 kB, SVN, the website is... difficult but there seem to be a lot of examples, according to http://ormlite.com/changelog.txt the last version is 4.48 from 2013,
https://github.com/j256/ormlite-core (release tags), last activity March 2015
http://greendao-orm.com, good maintenance, Maven artifact, focus: fast performance, small size, little RAM consumption. Github: https://github.com/greenrobot/greenDAO/ (release tags, > 2300 stars), last activity November 2014
https://github.com/roscopeco/ormdroid, small size, last activity August 2014
http://www.activeandroid.com, https://github.com/pardom/ActiveAndroid (> 2300 stars), good maintenance, community, no release tags (download points to master tarball), Maven artifact, last activity October 2014
http://droidparts.org, https://github.com/yanchenko/droidparts (release tags, > 600 stars), also dependency injection, Maven artifact, actively maintained
http://www.androrm.com , https://github.com/androrm/androrm (release tags), last activity Jan 02, 2014 (github)
https://github.com/emilsjolander/sprinkles (release tags, > 600 stars), last activity May 2014, Maven artifact (thanks #AndroidGecko)
http://realm.io, https://github.com/realm/realm-java replaces not only ORM but also SQLite, also for iOS (release tags, > 1600 stars), actively maintained, own Maven repository
I have not tried any of those but maybe I can spare current readers a bit of time by listing the nowadays active projects. Please add a comment if you know of other projects that satisfy some of the above points and have some serious development (over some time) going on.
EDIT (2013 Nov): updated the list to the current status of the projects. Some of these have added release tags to their github repos as well as Maven/Gradle support. Good work!
EDIT (2015 Apr): updated the list, added Sprinkles (as per comment by #AndroidGecko) and Realm.io.
If performance and code size matter, check out greenDAO. I'm the author of it, and my motivation to create another ORM was to avoid reflection in the hotspots. It turned out that greenDAO can be up to 4 times faster than ORMLite. Checkout the feature page for details.
I don't know of anything that is exactly what you are asking for, but there is an alternative to SQLite that you may find useful if your architecture requirements are flexible. It may be worth checking out db4o:
Android db4o
Code comparison examples
ActiveAndroid ($20) looks like it may be exactly what you need.
I liked ActiveAndroid. It's written specifically for Android it seems. That's feels like a plus to me.
I have some Ruby on Rails experience and if you like the Rails way of ActiveRecord you can very quickly get moving with this library.
https://www.activeandroid.com/
https://github.com/ahmetalpbalkan/orman
Orman framework might help you. It is especially designed for that and very small and useful.
I'm also looking for an ORM on Android. I tested ActiveAndroid, NeoDatis and db4o, and I think that I'll use one of the two last.
NeoDatis and db4o are really similar, so I would like some advice to choose the best one. Is someone using one of them on his project ? I'll use it for free and paid app, but it seems that the two haven't any license limitation for Android.
There is a benchmark here that seems to say that NeoDatis is faster than db4o, but I don't know if we can base my opinion on this.
One more newcomer: android-active-record.
It's very lightweight and easy for use persistence framework for Android backed by SQLite
http://code.google.com/p/android-active-record/
ActiveRecordJS from Aptana is a Javascript ORM that should run on the gPhone. It is designed to work with Jaxer and Gears. When you user the Jaxer Adapters, you can connect to SQLLite.
UPDATE: I don't think I made it clear, but ActiveRecordJS is an ORM that runs client side, which could be an advantage to you on the gPhone.
http://hadi.sourceforge.net
This tool is very simple and easy to use.
I have developed my own implementation of the JPA ORM for Android. It is not yet fully feature complete, but you can annotate class with the #Entity, #Id, #Column annotations and you get JPA entities that can be stored and retrieved from the SQLite database. It needs some more features & cleanup before I'll post it to the public, but if there is enough interest it might accelerate my effort.
Even though this is an old post, the topic is still relevant. Hence, I want to share an interesting article and nice approach to solving most of the issues mentioned in the question:
http://blog.codecentric.de/en/2011/04/android-persistence-accelerated-small-inhouse-orm/
Hope anyone finds this as useful as myself!
My own DroidParts /http://droidparts.org/ just reached v0.5. It's a DI/ORM library & more.
Not much documentation, but includes a sample app.
Had negative experience with db4o (v. 8): indexing didn't work properly (exception etc.). So I didn't managed how to avoid creating duplicates in foreign tables when having object in object structure. More detailed explanation in my question. Hope one day it would be better.
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.