Panasonic Youth rob sanheim writes about software, business, ruby, music, stuff and things

Top Five Worst APIs in Java

Its monday morning and I forgot my coffee thermos at home. Drinking corporate coffee sucks. Guess I might as well complain about Java.

• Calendar - Bad.
• Date - Worse? Date and Calendar might be the most ridiculous Java APIs ever created. With date you can at least say getYear or getMonth, but then the results are the weird “year represented by the date, minus 1900″. With calendar you have the wonderful abstract get approach - ie myCal.get(Calendar.YEAR), myCal.get(RANDOM_MEANINGLESS_INT). Would an immutable, easy to use date object be too much to ask for? Couldn’t Java 7 just incorporate JodaTime or something?
• BigDecimal/BigInteger - Steve covers this one must better then I can. Even incredibly simple calculations become a horribly verbose mess with the BigNum objects. One case where you really need operator overloading.
• ResultSet - why can’t I just iterate over everything in my row? Why can’t I get a map of the values keyed by column header?
• Format, NumberFormat, DateFormat, etc. - SimpleDateFormat really isn’t, and these classes end up making the smallest task difficult in order to have ultimate flexibility. Not a great trade off for most cases.

So how would you redesign NumberFormat and SimpleDateFormat? I’m not sure I’ve ever considered them complicated, but maybe I just can’t imagine the alternative.

ResultSet would be my personal worst - especially since I had to implement it for one of my projects!

Not sure here, but about ResultSet:

* You can iterate over everything in your row, but you have to use the keys found in your ResultSetMetaData, just as you would with a HashMap.
* There also exist this Rowset thingie, and disconnected ResultSets, in case you need them.

Agree (as everyone does) on the DateFormat, Date, Calendar, etc issues. I had to implement a couple of compilers for simple messages and had to reimplement the whole Format APIs because they were so damn incomplete for real use (such as error recovery).

I don’t think I could leave out java.util.Properties. By subclassing Map, they expose all the Object-ish parts in addition to the String-ish new interface, leading to either confusion or misuse. Also, the inner defaults don’t work as you expect they should. Cloning is tragically broken in any useful way. Many useful utilities are missing from it. This thing should be shot and left for dead.

Don’t forget Boolean! In contrast to other wrapper classes, there is no easy way to convert a String to a primitive.

Good:

int x = Integer.parseInt(”1″);

Bad:

boolean b = Boolean.valueOf(”true”).booleanValue();

BTW: I don’t understand what’s bad with the …Format classes, too!?

Nah, the abolutely worst of the worst is some Swing classes having public RCSID fields, i.e useless artefacts of the source code respository utility being exposed as an equally useless API.

One would think there would be some sort of QA at the J2SE JSRs, but apparently, far from it.

Or the java.awt.peers junk in java.awt.Toolkit. It’s awesome and next to useless to get handles to undocumented classes.

Or some Swing APIs in 1.5 taking undocumented sun-specific classes as parameters. etc.

If Java was developped like real standards are, with mutliple implementations of the new APIs before they are dragged into the standard and rubberstamped, it wouldn’t have to suck so badly. The mediocre first attempts at designing APIs would not have to be cemented forever as the one true standard.

Sigh.

cheers,
dalibor topic

bah! BigDecimal/BigInteger were done by The Man

Alex: Agreed on both counts - properties are annoying, and cloneable is just hopeless. Bloch has a good section on cloneable that basically says 99% of the time don’t use it - provide a copy constructor instead.

I am Iranian we have another calendar (Jalali) which is different then Gregorian calendar used in western countries.
I understand the reason of current design of date and calendar which is necessary for internationalization the same also applies to formatter classes, I agree that the API can still be optimized.

I’ve got two additional bad classes:

java.util.Observable was a good concept but it should have been an interface. Due to this flaw, I don’t think I’ve ever seen anyone use it!

java.net.HttpUrlConnection comes close, but bugs and an awkward API prevent it from being useful for serious work.

In your next post, I think you should suggest the JDK’s 5 best classes!

I have to agree on the Date issue. At JavaOne 2001 I attended the Birds of a Feather session called “Meet the Core Team”, where amongst others Bloch attended.

When questioned about the design of the Date class, the core team simply said: “We’re sorry”.

They also had very little to say about some of the stuff in the IO package, and some of the annoying stuff was indeed fixed/improved in the New IO package.

Regarding ResultSet’s; I wrote a set of classes where the main one is called DBEntrySet, and it parses the content of a ResultSet and stores it in a list of HashMaps. I added the get-methods from the ResultSet and also made it possible to send in a default value to return if no entry was encountered (as in Properties).

At first I only needed this in order to pass around the results of a SQL query after the connection had been closed, but now I always use it, since the data is more easily accessible than in the ResultSet.

When I learned Java, I was a Perl programmer. Coming to Java and having to learn the RegEx API was a real pain in the ****… So I’ll add that as well. I could also mention anything that has to do with URLs… How come Sun uses rather strange names for the different URL parts. And even better, there’s absolutely no example about what this part would be in URL xyz.

I agree that java.util.Date is the worst API in Java.
Besides two of the constructors, only after(), before() and get/setTime()
are not deprecated!!!
I think java.util.Date is not a class, is a design flaw with a name.

As for the *Format classes, i think they are well designed.
The base Format’s abstract format and parse methods have FieldPosition
and ParsePosition to keep track of parse/field position, aswell parse error
information.
About the *Format classes, only MessageFormat has 2 serious problems:
-doesn’t behave well with contiguous and similar formats on parse (as the first gets greedy);
-doens’t support more than 10 (indexed 0 to 9) parameters

i had to work with the Calendar a few companies ago, with respect to it’s time zone and calendar assignments for all the countries of the world, and it had numerous bugs. i remember, for instance, having to assign a Polish time zone to a country in africa because java.util.Calendar had it incorrect.

still, it was kind of fun ringing up all these embassies (a local call, i work in d.c.) and asking when/if they observe DST…

How about Swing? One could not possibly declare it a success, with IBM starting their own widget-kit (SWT) to counter the issues such as:

- Layout management that is either too complex for humans or too simple for anything beyound college projects (GroupLayout is welcomed!)

- L&F which requires you to write custom renderers for each and every possible component, good luck with getting a consistant look if you require 3′rd part components (and for serious apps, you do).

- Although significantly improved by Tiger, Swing applications still makes my 4400+ dual core CPU feel like I am running on a 486.

Casper: I haven’t had the “pleasure” of doing any AWT or Swing work on anything more then toy apps. Sounds like it has been a struggle, at least until Matisse.

Swing can get complicated–since you end up having to create tons of panels to get things oriented just right–but I haven’t found it to be slow. Just keep the GUI thread free by spinning off event actions into new threads and you should be fine.

All of the one-size-fits-all, hollow-out-the-round-hole-until-the-square-peg-fits, abstraction-of-a-single-implementation APIs:

JNDI
JCA/JCE
JavaMail
javax.xml.*

BigDecimal and BigInteger for me. Just try overriding toString to output a number in a format you’d expect. It causes all kinds of problems.