Java core API anti-Patterns. What is wrong?

Question

Hi, Despite that the work of the guys from SUN with the Java core API is awesome, as they are humans, they are not infallible. I have read in several books some criticism about Some huge mistakes that (my guess) are still there for backward compatibility and legacy code. My question here is which ones do you know?

As examples:

• Observable is a Class. Should be an interface in order to allow inheritance.
• Cloneable: It shouldn't be a marker interface. (Should have the clone method instead of be in Object class).

Answer 1

• Observable has to be a class so that it can actually store the Observers and call them with updates. However, it's pretty trivial to write your own MyObservable - for instance I frequently use a RMIObservable that fires the update over an RMI link.

• The Date and Calendar classes suck rocks.

Answer 2

Public instance fields in many AWT classes

Answer 3

Stack inherits from vector rather than simply holding one, giving stacks vector methods and allowing clients to trivially break the abstraction. A classic example of inheritance being used when composition should have been.

Answer 4

Stack extends Vector! insanity.

if I am using a stack object I expect users to be able to push and pop, and err, thats about it.

The java Stack also has all the vector functionality like get and set.

A Stack class that had a vector member variable, and only exposes the methods that a stack should have is how this should have been done, imho. This is a great example of where Composition is more appropriate than inheritance.

Josh Bloch's excellent Effective Java book is a great book to read, and he points out several flaws in the Java API very eloquently. He has obviously thought long and hard around the subject, seeing as he was one of the Java architects.

Answer 5

• java.util.Calendar is a example of bad API design. Try to calculate the difference in days between two calendars and you will see that code is not readable/clear/succinct. APIs to handle dates in Java are bad. But things is getting better.
• Some parts of Collections API. Per instance, "sort" must be a java.util.List method (they can't do it now because of compatibility); "Stack extends Vector" and lack of ways to handle collections in a easily (predicates, transformers, filters, etc)
• Layout managers in Swing: powerful, but totally complicated.
• java.util.Properties is a HashTable. Non sense!

Answer 6

In addition to the Observable, Date and Calendar suckiness that others have mentioned:

• Class equality depends on the identity of the classloader. The result is that serialization and everything that depends on it is inherently broken.
• the java.util.URL class. Equality of two distinct instances can change depending on whether you are online or not. Also, the classloader mechanism uses this class for some unfathomable reason.
• the XMLGregorianCalendar that isn't... in other words, despite its name, it is not actaully a GregorianCalendar.
• Every object in Java is a mutex, and has wait(), notify() and notifyAll() methods. While the synchronized keyword is very useful, I think it should be limited to objects that implement some Lock interface or something like that - like how the for-each loop is only useable on Iteratble objects.

Answer 7

Bit of an open-ended question this one. Even in Object:

• clone. Just remove it - no replacement. Absolute evil.
• finalizer. Gah.
• wait/notify/notifyAll. Wrongheaded approach to threading.
• hashCode. Seems unfair to support hash but not ordered structures. Also it (together with ==) make small immutable value objects less efficient.
• equals. Asymmetric. Should NPE on null argument.

Answer 8

• Properties extends Hashtable. Aargh.
• Every object being available for locking instead of specific lock objects(.NET has the same problem)
• Every object having equality/hashcode - again .NET has the same problem, but at least they have IEqualityComparer<T> as well as IComparer<T>. This is the way that all maps etc should go, as there are multiple concepts of equality depending on circumstance.
• The date/time API (new version in Java 7, I hope)
• The async model of NIO is harder to grok than the async .NET model
• No universal disposal interface - partly due to checked exceptions - which makes an equivalent of the "using" statement harder to cope with
• Poor text encoding support (too much use of names as strings)
• No unsigned byte type

Answer 9

Date being mutable

Answer 10

 Boolean.getBoolean("true");
 Integer.getInteger("2");

.....

Answer 11

One big mistake was to create String(byte[] bytes) constructor and String.getBytes() method. They are the source of many problems with character encoding in java.

Those developers who know nothing about encodings use these methods without care. Code works on their environment and in their language. Bad luck if you have to reuse their libraries.

It is OK to use default encoding if you use it consciously. String(byte[] bytes, Charset charset) and String.getBytes(Charset charset) helps you be conscious.

Answer 12

From what I can tell, SimpleDateFormatter is convinced weeks start on Sunday and can't be dissuaded from this idea.

Answer 13

Constructor of javax.naming.InitialContext requires Hashtable instead of a Map.

Answer 14

In the String class:

public String(String string)

I don't know how many times I've seen code like

String cancel = new String("Cancel");

Sadly, this is the first example of a constructor introduced in Thinking in Java.

Answer 15

The java.sql API used to drive me crazy with its exception model. SQLException being a checked exception has led to enormous quantities of bad code around SQL calls: There's a million of DAO methods that either throw SQLException themselves, or just swallow or log exceptions. It should just be an unchecked exception: Unless you're building an SQL GUI tool, SQLExceptions usually mean that your code is broken or there's something wrong with the database server.

At the same time, SQLException doesn't give you much usable information on what went wrong - if you want to deal with errors in any meaningful way, you're forced to parse RDBMS-specific error messages.

This has been less of an issue since we have useable ORM frameworks. The Spring framework has also helped with it's higher-level JDBC support code and exception model.

Answer 16

You can fake unsigned integer types by going up one storage class (byte->short, short->int, int->long). But you can't get an unsigned long.

Answer 17

Lots of uses of the Interface Constants anti-pattern, especially in Swing.

Answer 18

Iterator is in java.util, while Iterable is in java.lang, although it depends on Iterator. Wrong package dependency :-(, thus these packages are effectively tied together.

Answer 19

RuntimeException should not inherit from (Checked)Exception. It should be reversed (and named changed to reflect this), or RuntimeException and CheckedException should both extend Exception, and Exception and Throwable should have no public constructors.

Answer 20

My personal least favorite is that they have to retain the lovely public static final int literals for every pre-1.5 class. Why can't they enum clean the code base, por favor?

Answer 21

java.awt.BorderLayout uses NORTH, SOUTH, EAST, WEST instead of TOP, BOTTOM, LEFT, RIGHT. I also like the way they need to clarify it in the comments for those contants:

/**
 * The north layout constraint (top of container).
 */
public static final String NORTH  = "North";

Answer 22

Here is a little list I have put together Java Convention Failure

One of my favourite is the rather long class name com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

A non-haiku I wrote in its honour ;)

Internal frame
internal frame,
title pane
internal frame.

title pane
maximize button,
window not focused state

Answer 23

Having public constructors instead of static factories that would return interfaces. Now they are stuck with concrete classes, and its harder to optimize things, or fix problems.

Answer 24

Its not an API issue, but a core anti pattern for me is not allowing unreachable code. I definately don't think unreachable code should be encouraged but a warning (C# style) would be fine. I don't know how many times I've had to do this:

if (true) throw new IllegalStateException("Testing... 123");  

// Unreachable code ....

Its worse still if you want to skip a block of code temorarily, i.e. you need to wrap it in if (false) { ... }

Answer 25

java.awt.Graphics.drawImage(Image img, ...) only accepts BufferedImage at runtime.

If you subclass Image and try to draw it, you get an IllegalArgumentException: Invalid Image variant.

And admitting this in a comment is even worse, if you look up in the source code you will see:

/*
 * In practice only a BufferedImage will get here.  
 */

Answer 26

The List's toArray() methods:

T[] List<T>.toArray(T[] a)

I understand that they had to keep the original method for backwards compatibility but why did they only add Arrays.asList() without adding Arrays.<T>toArray(Collection<T> c)?

It makes working with JTree selection painful: tree.setSelectionPaths(selectionPaths.toArray(new TreePath[selectionPaths.size()]));