| MAIN : JAVA RANTS AND RAVES : SINS OF THE JAVA FOUNDATION CLASSES |
| 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. |
| Standardization |
|
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: |
| Language |
| I consider the lack of Generics is a bug in the Java Language. See GJ for an interesting backwards-compatible implementation. |
| Packaging |
| 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. |
| Time |
|
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. |
| Javadoc |
|
[ FIXED ] I love javadoc. However, there is no way to document a package from within javadoc! |
| java.awt.List |
| 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 |
FileDescriptorThis is a useless abstraction.FileFiles 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[ IMPROVED ]There is no concept of a file system or device within the Java foundation classes. This is, I believe, a conceptual bug. Reader/WriterWhy 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 PushbackReaderYou can push back either an array of characters or a single integer. Huh? Why would you push back an integer and not a character? |
| String |
hashcode[ FIXED ]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. internDon't try to use String.intern too many times ... there's a limit on the absolute size of all strings. |
| StringTokenizer |
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");
st2.hasMoreTokens();
System.out.println("With call: " + st2.nextToken("c"));
}
}
|
| JDBC |
|
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 |
| Collections are currently in java.util, but would be much better off in their own package. |
| java.util |
| 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 |
|
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: |
|