The Top 10 Ways to get screwed by the "Java" programming language

Last modifiedMarch 28, 1999.

Better languages allow fallible programmers to be more productive. Java is not cast in stone, so perhaps some of these complaints can be addressed, if not in Java then in Java2.  In any case, whether fixed or not, awareness is a big step toward avoidance; so read on!

1. Know your classes.  The rules for locating the classes to use are complex, and not consistant from one environment to the next.  Consequently, it's easy to be confused about which classes are actually being used.  And if you don't knwo what classes are being used, you have no hope of understanding your program's behavior.  Here are some aggrevating factors:
• Some versions of appletviewer lookf for "jars", some look for "zips", some loop for neither.  JDB looks never looks for jars or zips, even when the corresponding versions of appletviewer without jdb do.  Worse, no programs seem to notice archives that haven't been updated.  Consequently, archive files tend to be a booby trap during developement.
• if "." is included in CLASSPATH, you can get different results depending on the current directory is.  I suspect some java implementations give you "." whether you want it or not.  Some java implementations are not cautious enough about picking class files with the correct name, but when the internal class name is evaluated relative to the current element of CLASSPATH, can give an incorrect actual class name.
• Both Netscape and Internet Explorer will use classes found relative to your local CLASSPATH in preference to classes downloaded from remote web sites.  This "feature" makes it difficult to debug classes installed on remote sites, since you must be very careful to "hide" your local classes from the browsers.

 
2. Thread with wild abandon, and without a safety net.  Java virtually requires you to use 3 or more threads for even a very simple program (threads for paint, event, run), but provides only the most basic synronization primitives.  I wrote about this problem at some length in my Javaworld review of Assure.

 
3. No "enum" type.  How this was omitted from the language is beyond understanding.  In Java you have two uncomfortable choices when you need to enumerate a small class of constants.

 
1. clumsily define classes, and instantiate a limited number of members

class myChoice
{ String name;
   Static final myChoice usual_choice = new myChoice("usual");
   Static final myChoice other_choice = new myChoice("other");
}

void DoIt(myChoice choice) { ... }

Adding to the insult of this choice, switch statements cannot use myChoice instances as cases.
 

2. define constant integers and be very careful.

static final int usual_choce = 1;
static final int other_choice= 2;

void DoIt(int choice) { ...}

of course, any old "int" will be acceptable, not just one of the expected choice constants, so beware!


 
4. Reserved for future expansion. Send email to ddyer@real-me.net with your suggestions.