I am a big fan of Java and the Java Foundation Classes (JFC) that Sun has come up with. However, I would like to see changes in the class libraries. Here are some critiques that I have collected about various things that have bothered me at one time or another. They might not all bother me anymore.
I believe there is an inherent conflict of interest in Sun being the standards body group in charge of Java. I think they have good intentions for the most part, but they have additional motives that should not play into making a standard.

Sun COO Ed Zander from PC-Week:
"You have to run a business that produces revenues and profits. We're not in this business to be a philanthropist to the industry."

I consider the lack of Generics is a bug in the Java Language. See GJ for an interesting backwards-compatible implementation.
The JDK and a JRE that both contain a Java Virtual Machine. I think there should only be one Java VM, and that the JDK tools, which include javac and javadoc, should be distributed separately.
java.util.Date, java.util.Calendar, and java.util.GregorianCalendar are totally broken from a design point of view. (They were also broken functionality-wise before 1.1.4.) The 1.1 specification of Date is not too bad. However, java.util.Calendar has in it notions of month name, day of week name, and so forth. It has no provisions for any calendar other than Gregorian Calendar, so calendars such as a lunar calendar or a Chinese calendar or other calendar would not be integratable into this system.

For the Gregorian calendar, it is difficult to get the first day of the week for a month/year combination, or to get the number of days in that month.

I love javadoc. However, there is no way to document a package from within javadoc!
How do you assure that the list will be wide enough to display the entries without a horizontal scrollbar? My guess is that you don't.
Java I/O


This is a useless abstraction.


Files are created out of thin air. Shouldn't they be created off of some drive or filesystem? Shouldn't there be a different object for File and for Directory?

File systems

There is no concept of a file system or device within the Java foundation classes. This is, I believe, a conceptual bug.


Why are there so many of these? Shouldn't there be only one of each (add maybe PushbackReader), and everything else is an InputStream or OutputStream?

Unread in PushbackReader

You can push back either an array of characters or a single integer. Huh? Why would you push back an integer and not a character?


Strings are immutable. However, the hash code for a string is calculated every time it is requested, even though it will never change. Storage for the hashcode would be the equivalent of only two unicode characters.


Don't try to use String.intern too many times ... there's a limit on the absolute size of all strings.
hasMoreTokens() changes the internal state. An example modified slightly from coworker Ken Kocienda:
import java.util.*;
public class StrTokBug {
  public static void main(String[] args) {
    StringTokenizer st1 = new StringTokenizer("everclear", "e");
    System.out.println("Without call: " + st.nextToken("c"));

    StringTokenizer st2 = new StringTokenizer("everclear", "e");
    System.out.println("With call: " + st2.nextToken("c"));
JDBC is not a universal access method for relational databases. You have to compose different SQL for different databases; JDBC does nothing to hide the horrid ugliness of differences in SQL implementations. Thus it is as good as a video API that does not hide the inner workings of the video card.

JDBC does not provide transactional semantics.

JDBC does nothing to solve the impedance mismatch problem of mapping richly expressive objects to flat relational tables. (JavaBlend, a Sun product, does this.)

Basically, JDBC is encouraged as a first-line interface to persistence, but most people should not have to deal with its interface.

Collections are currently in java.util, but would be much better off in their own package.
Beware any package (or even file) called "util", "tools", "misc". These are generic dumping ground names, the contents of which usually are not made to fit into any particular system.
Serialization of a String is limited to 16K.

Serialization (in general) is not a good means for permanent storage because it prevents changes to object hierarchies. Persistence is therefore not solved as a general problem.

JDC Tech Tip
Tech Tips #7: On implementing Asserts in java ... "So if you want to check "should never fail" conditions, and terminate an application gracefully in such an event, try this technique. You should find it useful." Why not just throw an exception? See also this asserts in Java page.

Tech Tips #8: "Hashtable is extended from an abstract class called Dictionary, a name that clearly describes its purpose." I'd think a Dictionary is something that is a collection of one-to-many relationships, but java.util.Dictionary is intended to be one-to-one relationships.

Other lists of sins:

Last updated on Saturday, 18-May-2002 09:14:22 MDT.
You are visitor [an error occurred while processing this directive] since 05 April 1998.