Is the Java API poorly designed and why?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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..

Answer 6

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.)

Answer 7

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"!!!

:)

Answer 8

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. :-)

Answer 9

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.

Answer 10

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.