I spoke on this topic in 1997-11 at the Colorado Summit Conference, and again in 1999 November.

Inconsistent Extensions

CD \MyDir
javac.exe -classpath . HelloWorld.java

CD \MyDir
java.exe -classpath . HelloWorld

<applet
code="HelloWorld.class"
width="230"
height="240">
<img src="image/NoJava4U.jpg">
</applet>

We Aren’t In Kansas Anymore

if ( width )
   {
   widen( width );
   }
if ( myDog )
   {
   myDog.bark();
   }

if ( width != 0 )
   {
   widen( width );
   }
if ( myDog != null )
   {
   myDog.bark();
   }

if ( tooWide )
   {
   widen( width );
   }

if ( tooWide = true )
   {
   widen( width );
   }

Default Fall Through

switch ( k )
   {
   case 1:
      System.out.println( "hello" );
   case 2:
      System.out.println( "hi" );
   }

Because the syntax for defining cases and labels is so similar, it is easy to make an error like this: The programmer left out a space and, instead of handling n == 3, he defined a goto label called case3 in his switch statement.

switch ( n )
   {
   case 1:
      ...
   case 2:
      ...
      case3:
      ...
   case 4:
      ...
   }

String.replace

// String.replace produces a new String. It does not modify the original.
// Since String is immutable, no method cAN modify the original.

String aa = "peal";
String bb = aa.replace( 'a', 'e' );

System.out.println ( aa + " " + bb );
// Prints "peal peel" not "peel peel"
// Newbies often expect String aa to be changed too.

Microscopic Fonts

// OOPS, DON'T DO THIS!
component.setFont( new Font( "Dialog", 12, Font.BOLD ));

// do this instead:
component.setFont( new Font( "Dialog", Font.BOLD, 12 ));

Font.createFont produces a font 1 point high, too tiny to see. You must use Font. deriveFont before you can use it.

double Double Toil and Trouble

You need to treat primitives as objects for another purpose — so that you can put them into containers such as ArrayLists or Vectors. In Java, you must manually wrap your primitive up in an object. Sun provides a set of immutable object wrapper classes called: Byte, Short, Character (not Char), Integer (not Int), Float and Double, the very same classes that house your static methods for fiddling with primitives! It might have been clearer had they called these classes names like ImmutableByte or ByteWrapper, but they didn’t. You can’t change the value of the primitive inside any of these wrapper objects. All you can do is create a new object with a new immutable primitive sitting inside.

To make matters all the more confusing, the Double class then has double duty, to deal with both double primitives and Double wrapper objects. The instance methods for Double manipulate Double objects and the static methods for Double manipulate double primitives. These methods naturally have similar if not identical names! The same problem occurs for all the other primitive/class pairs, but most newbies seem to trip over it first with

double d; /* double primitive */
Double dd; /* Double wrapper */
String g;
g = Double.toString( d ); /* double primitive */
g = dd.toString(); /* Double wrapper */

toString Blues

With the default toString, you just get the class name and hashcode of the object, which looks like gibberish, e.g. [C@ad3ba4.

char[] c = { 'a' , 'b' , 'c'};
System.out.println( c.toString() );

Label.toString() is not an alias for Label.getText(). It will print out a summary of the Label fields like this: java.awt.Label[label0,0,0,0x0,invalid,align=left,text=def]

How then do you convert to String? With a hodgepodge of techniques that rival French verbs for irregularity.

Is char a character or a number?

String x = "foo" + 's';

Octal

The Case Of The Disappearing Constructors

Even though a constructor is similar to static method that returns a new object, you may not declare the constructor static. It is not static, since it works on specific default object. this is defined in the constructor.

If you do any of these things, the compiler will think your constructor is just an ordinary method. You will be baffled by the compiler’s complaints that you have not defined a suitable constructor to match the arguments you provide.

It may help if you realise that new allocates/creates the object and the constructor initializes it. Therefore the constructor has no need to return an object.

If you don’t provide any constructors at all, Java will automatically provide you with a default constructor the form:

public MyClass()
   {
   super();
   }

private MyClass( int fudgicles )
   {
   this.fudgicles = fudgicles;
   }

You will most likely come across this problem when you see the following error message:

In English, it means you are missing the default public constructor for your Applet. See constructor.

Missing Hex

The new hex Unicode technique "\u003f" has a catch. It is not suitable for encoding control characters. It is evaluated in a pre-processor pass and converted to a character, then the code is compiled. If for example you wrote "\u000a", this gets converted to:

"
"

Math.sin

double x = 90;
double y = sin( x );
double z = tan( x + PI );

// converting degrees to radians, manually.
static final double CONVERT_DEGREES_TO_RADIANS = Math.PI / 180;
double x = 90 * CONVERT_DEGREES_TO_RADIANS;
double y = Math.sin( x );
double z = Math.tan( x + Math.PI );

1. the Math package works in radians, not degrees. 360 degrees = 2 pi radians.
2. You need the Math.sin instead of plain sin because sin, cos, tan etc. are static functions. Compared with other languages you may have used, Java is picky and verbose. It wants the "Math." even when there is no name clash with a sin function in some class other than Math or some package other than java.lang. Java wants to avoid even the possibility of an eventual name clash by making you qualify with Math.sin now. In a similar way, you must precede all static function and method invocations with the classname.
3. You need the Math.PI instead of plain PI because PI is a static constant. In a similar way you must precede all static constants with the class name.
4. JDK 1.2 has added two convenience methods:

   // built-in radians <-> degrees methods.
   public static double toDegrees ( double angleInRadians );
   public static double toRadians ( double angleInDegrees );

Further, every time you do a floating point calculation you loose a little precision. It all adds up.

In Java 5.0 you no longer need the Math. in Math. sin() so long as you add an import like this:

import static java.lang.Math;

Where’s the Beep?

In JDK 1.1 You can make a simple beep with j java.awt.Toolkit.beep(). I have seen reports that beep does not work properly on some platforms.

In JDK 1.0.2 you can use

System.out.print ( "\007" );
System.out.flush();

See sound in the Java & Internet Glossary for more details.

Where’s the Root Directory?

File dir = new File( "C:\\" );
String[] files = dir.list();

File dir = new File( "C:\\." );
String[] files =dir.list();

This makes reading Strings representing filenames confusing. Unix systems use the "/" path separator character instead of "\". Macintoshes use ":" and have interesting twists like "::" for up instead of "/../" as in Unix. To write platform independent code, you should use the system file.separator and path.separator, or use the File methods that construct filenames for you from parts.

Then you might well ask, how do you find out which drives are available? In JDK 1.2 there is a new method:

File[] roots = File.listRoots();

For Each Gaps

Unstoppable for

for ( long i=Long.MAX_VALUE -2; i<=Long.MAX_VALUE; i++ )
   {
   /* ...*/
   }

Upper Case Surprises

if ( 'a' <= theChar && theChar <= 'z' ) theChar -= ('a' -'A' );

String.substring

"abcdefg".substring( 3, 5 ) gives "de".
"abcdefg".substring( 3, 7 ) gives "defg".
"abcdefg".substring( 3, 8 ) gives StringIndexOutOfBoundsException.

If you specify offsets that are outside the span of the string, you don’t get a truncated or null string; you raise a StringIndexOutOfBoundsException. One way to remember the way it works is that you specify the first character to include and the first character to exclude. But not quite. You are allow to be just barely past the end.

"emptiness".substring( 9 )

"emptiness".substring( 10 )

Why do it this way?

• Often you have an index scooting along a string, pointing the beginnings of each token in succession. To pull out the token you need only the old and new values of this index.
• Edsger Dijkstra (one of the earlier pioneers of computer languages) put up a logical argument for having range defined by their first value and value-after-the-end.
• the difference between the end and begin is the length.
• checking for empty range is done simply by checking if begin == end.

Then:

s = "APPLE".substring( 1, 4 ); // gives "PPL".
s = "APPLE".substring( 3, 3 ); // gives "".
s = "APPLE".substring( 0, 5 ); // gives "APPLE".

String tail = x.substring( endindex );

head = x.substring( 0, length );

Incomparable NaN

if ( Double.isNaN( d ) )

if ( d == Double.NaN )

if ( result != result )
   {
   System.out.println( "oops" );
   }

ValueOf and null

int[] intArray = null;
String.valueOf( intArray ); // produces the String "null"
char[] charArray = null;
String.valueOf( charArray ); // throws NullPointerException

Final vs Const

final Thing thing = new Thing( 7 );
thing = otherThing;  // generates a compiler error
thing.setSize( 10 ); // ok
thing.girth = 6;     // ok

Overflow

Watch out for chains of multiplied integer constants:

IBM’s BigDecimal and Archimath BigDecimal have provisions for detecting overflow and generating an exception. You can roll your own with code like this in standard Java.

If you know both values are positive, you can use a simpler overflow check. You could check if the sum is less than 0 or less than one of the two operands. I’m not sure if this catches all overflows, however.

Floating point arithmetic uses the IEEE error propagating scheme similar to that used in a spreadsheet to propagate invalid value flags to cells that depend on invalid values. In Java, though there is no overflow interrupt or notification, there is a good chance you will eventually find out about an overflow error when you see a java.lang.Double.POSITIVE_INFINITY, java.lang.Double.NEGATIVE_INFINITY or java.lang.Double.NaN showing up in one of your double variables. You can’t use == to test for NaN, you must use java.lang.Double.isNan().

Override vs Shadow

1. static method
2. instance method
3. static variable
4. instance variable

• Static methods are never selected dynamically; they are always selected based on the type information known at compile time.
• Instance methods always are selected dynamically based on the type of the object. The type of the reference or any casts are irrelevant. In C++ terms, all (non-final) methods are virtual. The main place this gets you in trouble is if you use a method in a constructor that is later overridden in some subclass. That method may use the subclass’s fields that have not yet been initialised by code in the subclass’s constructor. That method will just see subclass variables initialised to 0 or null.
• Static variables are always selected based on the type information known at compile time, taking any casts into consideration.
• Instance variables are always selected based on the type information known at compile time, taking any casts into consideration.
• There is no way to get at grandma’s method if mom has overridden it. Either grandma or mom would have had to given you a backdoor to that method with a wrapper around it by another name that was not overridden. Mom can of course use super to get at Grandma’s methods.

"broken" setLocation, setSize, setBackground, setForeground

1. Layout Managers. They do resize() and move() (the deprecated method names) on the contents of each container. Only the null layout manager will leave your sizes intact.
2. Generated code in Visual Cafe will do a move() and show() (the deprecated names) in an overridden show() method.
3. Your own code using deprecated names like move() or resize().

Unsigned Bytes

int i1 = b2 & 0xff;
byte b2 = (byte)( b2 + 1 );
byte b3 = b2;

• On every reference, you must mask off the generated sign-extending high order bits with & 0xff. Keep in mind that almost any operation on a byte will promote the result to an int.
• On every store, you must cast from int back to byte.
• The only time you don’t need the (byte) cast is when the right hand side is already a byte.
  

Modulus

Floored division is what you normally want when trying to figure out which bin an item belongs in. You can compute floored division as:

For computing how many fixed-size bins you need to contain N items, you want ceiled division, also known as the covered quotient. You can compute the covered quotient as:

Static Initialisers

static { calcPriceTab();}

The order of your variables that are statically initialised matters. Consider this little program:

The order of those three static finals is crucial to the results! You must put them in the order you want the calculations done. Java is not smart like a spreadsheet to do natural order recalcs for you. It will notice and either handle or reject such forward references when only literals and simple variables are involved, but as soon as you do things inside methods, it throws up its hands and says on your own head be it.

Instance Initialisers

1. the declaration
2. the constructor
3. an instance initializer block

The advantage of putting it on the declaration is that you need to specify it only once, not once for each constructor. This means there is less likelihood of error if its value is ever changed. The other safe approach is to put all your initialisation code in one method or one constructor and have all the constructors call it.

Constructor Initialisation

However, there is one particularly tricky problem with initialisation order. In general you must avoid calling any non-final methods in a constructor. The problem is that instance initialisers / variable initialisation in the derived class is performed after the constructor of the base class. This can cause a problem if the base class constructor calls a method polymorphically, since that method will be presuming its derived class fields have all been initialised when they have not.

So base class constructors can safely call private or final methods of the base class provided those methods directly or indirectly call only private or final methods of the base class. If you call methods in your constructor polymorphically, the compiler will not stop or warn you of the initialisation pitfalls awaiting.

Casts

There are four sorts of cast:

1. to expand a value:

   byte b = -42;
   int i = (int)b;

   This cast is nugatory, though you might want to use the cast as a documentation aid. It does some conversion work — sign extension.
2. to trim a value:

   int i = -16411;
   byte b = (byte)i;

   This style of cast actually may do some real conversion work — zeroing out high order bits.
3. to treat a reference as its superclass:

   Dog myDog = (Dog)aDalmatian;

   This cast is nugatory, though you might want to use the case as a documentation aid. All Dalmatians automatically have all the Dog fields, so this cast has no run-time overhead.
4. to treat a reference as one of its descendants:

   Dalmatian myDalmatian = (Dalmatian)aDog;

   At run time, this cast actually checks that aDog truly is already a Dalmatian, and raises a ClassCastException if it does not. It does not make any attempt to convert a Dog to a Dalmatian.
5. Casts with abstract classes and interfaces work the same way as classes.

• Casts sometimes mean convert something to something else. Other times they mean, don’t convert, just treat something as if it already were something else. Casting objects is a misleading terminology. Any actual object has a definite class, set when it was instantiated. Nothing can change that during the lifetime of the object.
• You can’t use casts the way you can in C++ to look at the same physical storage in two different ways, e.g. to overlay a short on top of a pair of bytes, and sometimes address the storage as if it were a short and other times as if it were two bytes. Java is cleverly designed so that you can’t write a Pure Java program that depends on the big-endian or little-endian format of internal storage. (All external representations are big-endian). To break a short up into bytes you have to shift and mask.
• You might logically presume that casts are for converting one type into another. You might attempt code like this:

  String s1 = (String) i;
  int i = (int) s2;
  String s3 = (String) myDalmatian;

  Yet casting only works for two primitives. When there is a primitive and an object involved, there is a system of conversion functions with about as much regularity as French verbs.
• Whenever you store into an array of references, there is a type check done to make sure the object you are inserting is of the correct type. These checks can be quite slow.
• (String)is not smart enough to invoke the toString() method of an object.
• You can cast null into anything without raising a ClassCastException. Generally, this is a good thing. Otherwise every cast would need an if to specially handle the null case. You might be tempted to count on ClassCastExceptions to filter out nulls for you. The following code will not raise a java.lang.ClassCastException:

  Cat c = null;
  Object o = c;
  Dalmatian d = (Dalmatian)o;

  In other words, there is one universal representation for null, not a special one for each class.

  In contrast if ( null instanceof Dog ) is always false. instanceof does filter out nulls.

• What’s wrong with this code?

  Dog fido = new Dalmatian();
  int spots = (Dalmatian)fido.spotCount();

  Hint: What are you trying to cast to Dalmatian, the Dog fido or the int result of the spotCount method? When you are casting, you often need a forest of parentheses. This is what you should have written:

  Dog fido = new Dalmatian();
  int spots = ((Dalmatian)fido).spotCount();

• Parenthesis Forests: You think you have the hang of it? Look at this:

  (B)( ( (A)va.get( 0 )).b ).c = x;

  What does that mean? Get the first element of vector va (an Object), cast it to an A object which then, using field b, points to a another object. Cast that object to class B. In that object is a string reference c that you want set to x.

  That would be so much easier to read as:

  /* This won’t work in Java! */
  va.get(0):A.b.c:B = x;

  In getting those ()((()()))) right, count +1 for each ( and -1 for each ). You should get back to 0 at the end and any place you think you should be outside all (). You should never go negative. In that case above you count:

  1 0 1 2 3 2 3 2 1 0
  This is better than merely counting the number of ( and ) and seeing if they match, though it may take more mental effort.

  The problem is the infernal mix of prefix, postfix and infix operators that Java inherited from C. (At least the goofiness of String x [] is sort of gone).

  In a language with postfix casts and flatter precedence that might read:

  /* This won’t work in Java! */
  va.get(0) (A) .b (B) .c = "hello";
  You can similarly balance {} and [], though {} is harder since they can be widely separated. Best to use a smart editor. See parentheses (), brackets [], braces {}.

Implicit Casts

1. Automatic Assignment Conversion converts an expression’s type to a variable’s type (ex. short value = 26). This type of conversion is allowed when converting from a type to that same type (identity conversion), when performing a widening conversion, or when performing a narrowing conversion which assigns an int to a byte, short, or char variable where the int is representable by the (byte, short, or char) variable. Note that this form of conversion occurs only in assignments that preclude exceptions by definition.
2. Automatic Numeric Promotion homogenates operands to allow an operation (ex. 1.0f + 2.0 will cause 1.0f to be promoted to a double).
3. Automatic Method Invocation Conversion occurs when passing arguments during a method invocation (ex. calling methodA(45) on a method defined as methodeA(long value)). Except for disallowing implicit narrowing of integer constants, this form of conversion’s behavior is identical to that of automatic assignment conversion. Note that this form of conversion occurs only when the argument types passed to the method can be automatically converted to those specified in the method signature in a manner which precludes exceptions by definition.
4. Automatic String Conversion allows any type to be converted to type String. This occurs when the "+" String concatenating operator is used (ex. String resultString = "the answer is:" + result, where result can be of any type)

Concatenation

System.out.println(" x+y " + x+y );
System.out.println( x+y + " x+y " );

The way you most commonly get caught is is code like this where the last + is treated as concatenation.

System.out.println( "value: " + v + 1 );

The concatenation operator has the magic power of being able to implicitly coerce an int into a String by automatically invoking the
static String Integer.toString(int)
method, however, oddly, you can’t do the same thing explicitly with a (String) cast.

What do you think this little code snippet produces?

System.out.println( 'A' );
System.out.println( 'A' + 'B' );

The problem is Java’s design blunder of using + to mean both addition and concatenation. Addition also promotes to int, which println displays differently from char.

I really want this fixed. Concatenation should get a new operator symbol and using + for concatenation should be deprecated. The current scheme leads to code too easy to misread. + with int can mean either addition or concatenation. Deciding which depends too much on subtle context clues.

M y O u t p u t L o o k s L i k e T h i s

Finalizers Are Not Destructors

1. There is no guarantee that a finalizer will ever be called.
2. Finalizers do not automatically propagate up the inheritance chain like destructors. In particular, you should manually call super.finalize() from all your finalize methods. There is no guarantee about the order of invocation of finalizers.

1. System.runFinalization() Runs the finalization methods of any objects pending finalization.
2. System.runFinalizersOnExit(boolean value) Deprecated. It causes all finalizer methods to be invoked before exiting. This method is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.

Finally

public int square( int n )
   {
   try
      {
      return n*n;
      }
   finally
      {
      return 0;
      }
   }

Thread Safety

1. Implications of finalization on concurrent programs. In the Sun VM, there is a garbage collection thread that is responsible for freeing unreferenced objects and calling their finalizers. If your finalizer calls synchronized methods, you can wind up with very hard to debug deadlocks.
2. Should the implementation of method clone() from interface Cloneable be thread safe or not?
3. A rule of thumb is: never assume that JDK objects are thread safe. Do not think, "Oh, I bet I can guess the implementation, and it must be thread safe." For example, java.util.SimpleDateFormat is not thread safe, so things like this will cause strange formatting errors in multithreaded programs:
4. Swing components are not thread-safe. You must use javax.swing.SwingUtilities.invokeLater()/invokeAndWait() or EventQueue.invokeLater. in any code which might possibly be called by a thread other than the main event-dispatching thread. This crops up frequently in writing custom ListModels and TreeModels which respond to non-local or non-GUI events.
5. java.util.Hashtable and java.util.Vector are two examples of JDK objects whose every method is synchronized. This imposes a large runtime cost on applications that iterate over these structures. When you are not using threads, prefer java.util.HashMap and java.util.ArrayList respectively. If you are using JDK 1.1, it may pay to cannibalise the Hashtable code and remove the synchronisation.
6. Thread.sleep(5000) is supposed to sleep for 5 seconds. However, if somebody changes the system time, you may sleep for a very long time or no time at all. The OS records the wake up time in absolute form, not relative.
7. Thread scheduling is not guaranteed to be round-robin. A task may totally hog the cpu at the expense of threads of the same priority. You can use Thread.yield() to have a conscience. You can use Thread.setPriority(Thread.NORM_PRIORITY-1) to lower a thread’s priority. In Applets you need security clearance to even lower thread priority.

java.math.BigDecimal

For greater efficiency, you can often use a long or int, and keep track of the scaling yourself, and inserting a decorative decimal point on output.

BigDecimal is a travesty and deserves raspberries just like Date. Briefly, it slow, difficult to use, uses native methods, and it quietly drops off significant digits during conversion.

Also, java.text.DecimalFormat.parse returns either a Long or a Double. There is no built-in way to define custom number formatting for BigDecimalor BigInteger objects.

Fortunately, IBM has made available its proposed replacement for Sun’s class, which is 23 times faster, smaller, uses no native methods, and implements standard ANSI X3.274 floating arithmetic. For the spec see: IBM’s Decimal Arithmetic For Java and AlphaWorks. Dirk Bosmans has implemented the IBM spec as ArciMath. Another implementation is PSPDec.

java.awt.Graphics.drawRect

java.awt.Graphics.drawRect( int x, int y , int width , int height )

draws a rectangle one pixel bigger than the specified width and height. I am told if you understand the abstract drawing model the AWT uses, it turns out this extra pixel is deliberate and unavoidable. The rationale is that you specify the path of an idealised box drawn with infinitely thin lines, and the pen hangs down and to the right, at least one pixel thick.

java.awt.Graphics.drawString

g.drawString( "Hello World" , 0, getFontMetrics(getFont()).getAscent() );

GridBagLayout

• Write your own layout manager. It is not as hard as you might think.
• Override the getPreferredSize and getMinimumSize methods of your components. See the Deprecation Blues section. These methods used to be called preferredSize and minimumSize, and there are problems overriding deprecated methods.
• For Swing components, you don’t need any overriding. Have the object send itself a setPreferredSize() in its constructor or the client can send it before it is laid out, and the right thing will happen.

GridBagLayout will generate goofy layouts when components provide incorrect numbers for minimum and preferred size. For example TextFields don’t take into consideration setColumns or the size of the current font. All you can do is fudge using the ipadx and ipady parameters to inflate the minimum size.

GridBayLayout does not mind if you have a row or column with nothing in it. It will take no space. You might consider leaving some empty rows and columns in your layouts for future expansion.

weightx and weighty control where the extra space goes if the container is expanded. Think of them as percentages that don’t have to add up to 100%. They are automatically normalised. To figure out which column should get the most space, GridBagLayout examines each component in the column, and looks at its weightx. It saves the biggest weightx of all the components in that column as the weight for the entire column. It does not average them, or add them. Then it proportionately assigns the extra space based on the column weights. The component with a lot of weight does not necessarily grow, just the column that component is in. Giving equal but non-zero weight to columns tends to equalize their size.

GridBagLayout does the same thing allocating extra space to rows by using weighty.

The Insets(top, left, bottom, right) can be used to build a border around a component. The four numbers are measured in pixels.

If you want to fix the size of some element, you must use all three methods: setMinimumSize, setMaxiumSize and setPreferredSize.

Make sure you supply some non-zero x and y weights in your GridBag. Otherwise when you squeeze the frame down too small the components will act as if they had infinite space and will scoot madly offscreen to the right.

If you use GridBagConstraints.BOTH, forcing fill, that will override any setMaximumSize you may have specified on your panel.

Null Layout

• Has your enclosing container shrunk down to a point size 0,0? If so you can buttress it with Container.setMinimumSize( x, y ), Container.setSize(x, y); , Container.setPreferredSize( x, y ), Container.setMaximumSize( x, y ).
• Have your Components all got locations and sizes? I found, for example, that creating a JButton with an Icon was not sufficient to set the size of the button to the image size. you must do a Dimension d = jbutton.getPreferredSize(); jbutton.setSize( d );
• Have you positioned Components offscreen?
• Have you arranged for repaints?

• The code that uses the LayoutManager is perfectly normal.
• You can reuse the layout in other situations.
• Instead of doing absolute positioning, you might create something slightly more general purpose. You can still force the size of the container to a fixed value, avoiding all the comlicated parts of writing a LayoutManager.
• It segregates the positioning and sizing logic, thus making your code simpler to read.
• You can create more maintainable code. The LayoutManager does the calculations the programmer would otherwise have to do manually.

Deprecation Blues

setVisible() calls the deprecated show(), the reverse of that you might expect. You would think the deprecated method should bear the speed penalty of another layer of indirection. Yet consider what happens if you write a new setVisible() method to override one of the built-in ones. Users of the original show() method will be unaffected. They will continue to use the old code. Only those who directly call setVisible() will use your new routine. Now, consider what happens if you write a new deprecated show() method to override one of the built-in ones. All works properly; everyone will use your new method. You are thus stuck writing new deprecated methods if you want your code to work properly.

Let us say the AWT were redesigned so that instead show() called setVisible(). Then old code that used the deprecated methods would suddenly stop working.

This problem is general and applies to all deprecated methods. Let us hope Sun will soon get rid of the deprecated methods entirely, then this problem will go away. Most of the deprecated names are just name changes to fit the JavaBeans get/set conventions. Such deprecations could be handled as pure aliases by translation to the new names inside the compiler, and do away with the old classes entirely. However, that would cause a political problem of JDK 1.0.2 code no longer running under JDK 1.1 without recompilation or some translation process. You could not then have code that would run both under JDK 1.02 and 1.1. We would need to support the translation process in the JVM to have old code automatically use the new names. Sun is very reluctant to make any changes to the JVM.

The JDK 1.0.2 event handling routines are also deprecated. It is quite a bit bigger job to convert those. They could not be handled by a simple alias.

java.io.BufferedReader & BufferedInputStream

int BufferedInputStream.read( byte[] m, int offset, int len )

• until at least len bytes are available.
• until a buffer full of bytes are available.

int BufferedReader.read ( char[] m, int offset, int len )

The read routine has another problem. It traps and ignores IOExceptions rather than passing them on to you. To get around both the above problems, you can use your own read routine like this:

Applets Can’t Use The Local Hard Disk

1. Give the user a new security manager that has to be installed specially that gives permission to just your Applet to write to disk. Unfortunately, this won’t work if anybody else does the same thing. Security managers are still a black art. I have not yet seen any documentation on just how you would do this.
2. Convert your Applet to an application. The user has to download and install it, find and install some sort of standalone Java system for his platform, then run it. Whew!
3. Write a native class to cheat and do the I/O behind the security manager’s back. You will need to write such a native class for each different platform, then arrange to have it installed separately ahead of time. Ouch! Even then you still need security clearance to run the native class.
4. Use JavaScript or Active-X or some other gonzo scheme that cares not a fig for security.
5. Join the ranks of other programmers with their torches and pitchforks demanding some sort of chimera — half Applet/half application. It would be allowed access to a limited amount of disk space, and would not have access to any files it did not create. It could run inside a browser. This would have general applicability. You could do off-line data entry for example then upload, or retain application preference information, cache server data,…
6. Using the preferences of Internet Explorer, if you list an application’s site as a "Trusted Site", then if you set the security zone for "Trusted Sites" to "Custom" and change the settings such that Java permissions are "Unrestricted" and "Launch applications and files" is enabled, whew!, you will be able to write/read files from the local hard drive from within an Applet. Unfortunately Netscape has no equivalent feature.
7. Lobby for a generic user-configurable security manager, that lets users OK various naughty behaviours from specific Applets. The Applet would have an interface to request permission for special dispensation with minimum and ideal requirements.

Reconstituted Serialized Objects

• You may not append to the end of a serialized stream once it has been closed and reopened in append mode. The writes will appear to work, but when you go to read the file later you will get a java.io.StreamCorruptedException.
• In the creation of the serial stream, Java uses recursion. This limits you to a chain of about 1000 elements long.
• If you output an object twice to the stream because it has changed, only the first copy will actually go to the stream, unless you use the atomic bomb technique of resetting to make it forget all past history.
• When an object is reconstituted, the default constructor of any non-serialisable superclass is run, not the constructor that was actually used to originally create the object. However, no constructor of the serialised class itself is run, not even the default constructor. Further, the initialisation in the field instance declarations is ignored. The logic behind this would be, why bother to initialise when you are about to overlay with reconstituted fields? That is fine for ordinary fields, but it leaves transient fields uninitialised.
• Code to initialise variables as part of the declaration e.g. int q = 8; is ignored, (except in non-serialisable superclasses).
• Transient variables will just be set to 0 or null. Any initialisation code in a constructor or instance declarations will be ignored.
• Fields are serialized and reconstituted in alphabetical order, not necessarily the same order they appear in the object. This can lead to bizarre effects in reconstituting when you make a forward reference to a field alphabetically later than the current one since it has not yet been reconstituted.
• Static fields are neither serialised nor reconstructed.
• If you have a static singleton object that is also referred to by instance fields, an unwanted extra copy of the singleton object will be created on reconstitution. Each time you serialise and reconstitute you get more and more copies of the singleton object.

• Don’t use any transient variables. Serialise everything. Yet, when you have a peek at just how bulky serialized objects are, you won’t think much of this technique. You want to avoid serialising anything you don’t have to.
• Code so that the transient variables work even when they have default null or zero values. This is the simplest.
• Use the Externalizable interface, which is an extension of Serializable that add the readExternal and writeExternal methods. When Externalizable objects are reconstituted, their default constructor is used. The constructor also gives you a place to insert code to reconstitute static fields.
• Classes that implement Serialization should not use initializers. They should do all the equivalent work in an initTransient method and call it from both the constructor and readObject. This is ugly but safe.
• Check on every method entry, not just readObject and initialize the transient (yeach!).
• Call an initTransient method after reading your object (but it then has to be forwarded to the sub-objects, etc. Make it an interface.
• Derive the ObjectInputStream and make it call the initTransient (or check for the interface) in either the resolveObject or the validateObjects method.

"Broken" Repaint

Hidden Components Won’t Stay Hidden

I know of no method that will let you hide a component, that does not invalidate, thus leaving its space reserved, with no shuffling of sibling components.

Dialog.setBackground Does Not Work

public void addNotify()
   {
   super.addNotify();
   setBackground( Color.red );
   }

You also need to explicitly control the background of each component. Inheriting it from the Dialog will just give gray.

One further warning. In JDK 1.0, the modal feature of dialogs does not work.

Socket To Me

Until nio, there was no select() like functionality in sockets (or to be more flexible, in InputStreams) and there was no timeout in the InputStream.read() method. This makes it impossible to program a Socket server having a number of threads less than the number of users. However, I am told that if you use the available() method cleverly you can fudge it.

You have some control over timeouts with the networking system properties.

JSP Import Blues

If you use an include for boilerplate headers and footers then you may get a ClassNotFoundException if the included JSPs uses a custom class.

ASP developers are used to source code being dropped in by the ASP preprocessor and interpretted as one big file. According to this logic an import statement would be expected to appear at the top of the "page", where most ppl declare variables and define functions are in ASP. However in JSP, things tend to be split up and stay split up into many small files. You must thus make sure the import goes in each file that uses it, not just at the beginning.

Misleading Error Messages

See the table of error messages, now a separate document.

Credits

Unfortunately, the email addresses below are not clickable. Further you cannot copy/paste them into your email program. You must manually re-type them. The email addresses are graphic *.png images created by Masker . I inconvenience you this way to discourage spammers from harvesting email addresses from the website with automated website spidering.

Tov Are
Paul van Keep
Mike Cowlishaw
Pierre Baillargeon
Bill Wilkinson
Patricia Shanahan
Joseph Bowbeer