Daniel Pitts’ Tech Blog

So many Java programmers get loured into the Swing trap. I’m not saying Swing is bad, but it has some pitfalls that many programmers fall into simply because they weren’t told otherwise.

The biggest pitfall is that most Swing classes are not thread safe, and there is a specific approach you must take to communicate with these classes.

Where there are many ways to approach thread-safety, the designers of Swing choose the “thread-partition” approach. What this means in simple terms is that any time you want to access data or methods in a Swing class, you should do it on a specific thread. This is much easier done than said.

Normally when you access an object, you use “ob.member”, for example: textField.setText("foo"). In Swing, you need to make sure your code gets called only from the Event Dispatch Thread (that’s the “single thread” as designated by Swing).

Communicating from any thread to Swing

In order to get your code to run on that thread, you can pass a Runnable to the java.awt.EventQueue. If you don’t know, Runnable is an interface in the standard Java API that has one method, public void run(); For example, in the above “foo” example, I could do this:

public void setFoo() {
   Runnable setFooRunnable = new Runnable() {
     public void run() {
       textField.setText("foo");
     }
  }
  EventQueue.invokeLater(setFooRunnable);
}

EventQueue.invokeLater tells the Event Dispatch Thread (EDT) to execute that code at its earliest convenience. invokeLater returns immediately, which may have consequences if you expect things to be done. There is another method that lets you wait until the EDT has completed your task, but it is strongly discouraged to use it.

There was a time in the past when Sun suggested that you could initialize your GUI outside of the EDT. They were wrong. Yes, I said it. Sun made a mistake. They have since sent out a correction, but unfortunately the harm was done and you’ll see some tutorials exemplifying this dangerous practice. If you so as much create an instance of a GUI object, do so on the EDT under bane of glitch. It may appear to work, but it will crash sometime, somewhere, and you might not ever hear about it from the customer who decided not to buy.

Don’t block the EDT, ever!

There is another consequence of this single thread approach. If you do something that takes a long time, and you do it on the EDT, you’ll make the whole application unresponsive. Most GUI’s, Swing included, are Event Driven, so instead of waiting for something, you should listen for that something. Most Swing components allow you to add listeners to them. The methods on your listeners get called when something they care about happens. This lets you avoid things like “while (!isFooRead()); doSomethingWithFoo(getFoo());” and instead you have “public void fooIsReady(Foo foo) { doSomethingWithFoo(foo); }“.

EDT is lazy, don’t give it hard work!

For the same reason you shouldn’t block the EDT, you should move time-consuming tasks (IO, calculations, etc…) off of the EDT. Every millisecond you take on the EDT is another millisecond that a mouse-click doesn’t get registered, or the window doesn’t repaint. This will give your program the appearance of being slow and unresponsive.

Java 1.6 has added a new class called SwingWorker that helps you pass work between a worker thread and the EDT in a clean and “correct” manor.

Where to go from here

Hopefully at this point you’ve learned the basics of what it takes to write a proper Swing program. From here, I suggest reading Concurrency in Swing from the Java tutorials. For a much more complete understanding of the why’s and how’s of Java concurrency, I suggest buying and reading Java Concurrency in Practice.

Image this. You develop a Java application that uses only standard Java features. It only uses a hand full of classes, so you just distribute individually. It works great until someone using windows runs your program.

“Why am I getting ‘Exception in thread “main” java.lang.NoClassDefFoundError: FOO (wrong name: Foo)’?”
Remember, Java is case sensitive, but the Windows file system is *not*.

public class Foo {
  public static void main(String...args) {
    new FOO();
  }
}

class FOO {
  public FOO() {
    System.out.println("Works like a charm.");
  }
}

When you compile this on Linux, you get “Foo.class” and “FOO.class”, but on Windows, you only get one file. Oops!

So, its always a good idea to follow good convention with regards to capitalization. Use CamelCase, and treat abbreviations as words. Use XmlParser rather than XMLParser. Note that some of the standard Java API doesn’t do that (URL for instance).

Recently I’ve seen a few attacks on Java’s performance on comp.lang.java.programmer. So, I’ve decided to write my own benchmarks and test it myself. I expected the C version to perform slightly better, but at least in the same range, as the Java version. I was surprised that the Java version performed better, on both the client vm and the server vm.

I did my own benchmarks using these files:

bench.c

#include <stdio.h>
#include <time.h>

void bench() {
  long foo = 0;
  clock_t start = clock();
  for (long i = 1; i < 5000; ++i) {
    for (long j = 1; j < i; ++j) {
      if ((i % j) == 0) {
        foo ++;
      }
    }
  }
  clock_t end = clock();
  printf("%d %dms\n", foo,
     (int) ((end - start) * 1000 / CLOCKS_PER_SEC));
}

int main() {
  for (long i = 1; i < 10; ++i) {
    printf("%d: ", i);
    bench();
  }
}

Bench.java

public class Bench {
  static final long CLOCKS_PER_SEC = 1000;
  static void bench() {
    int foo = 0;
    long start = System.currentTimeMillis();
    for (int i = 1; i < 5000; ++i) {
      for (int j = 1; j < i; ++j) {
        if ((i % j) == 0) {
          foo ++;
        }
      }
    }
    long end = System.currentTimeMillis();
    System.out.printf("%d %dms\n", foo,
       (int) ((end - start) * 1000 / CLOCKS_PER_SEC));
  }

  public static void main(String[] args) {
    for (int i = 1; i < 10; ++i) {
      System.out.printf("%d: ", i);
      bench();
    }
  }
}

Then I ran these:

-bash-3.00$ java -version
java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
-bash-3.00$ javac Bench.java
-bash-3.00$ g++ --version
g++ (GCC) 3.3.3 (NetBSD nb3 20040520)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-bash-3.00$ g++ bench.c -o bench

Now I’m ready to run the individual tests:

-bash-3.00$ java -server Bench
1: 38357 457ms
2: 38357 416ms
3: 38357 401ms
4: 38357 394ms
5: 38357 394ms
6: 38357 401ms
7: 38357 395ms
8: 38357 401ms
9: 38357 394ms

-bash-3.00$ java -client Bench
1: 38357 421ms
2: 38357 400ms
3: 38357 394ms
4: 38357 400ms
5: 38357 393ms
6: 38357 393ms
7: 38357 400ms
8: 38357 394ms
9: 38357 401ms

-bash-3.00$ ./bench
1: 38357 450ms
2: 38357 440ms
3: 38357 450ms
4: 38357 430ms
5: 38357 450ms
6: 38357 440ms
7: 38357 450ms
8: 38357 440ms
9: 38357 450ms

As you can see, the Java version is approximately 10% faster than the c version. So, here is my challenge. Why is C so slow? I thought it was supposed to be faster than Java.

Updated: See notes below.

I was surprised to see that within one day of posting my previous entry on Operator Overloading, I received several comments. Aviad Ben Dov from Chaotic Java even took my idea and ran with it. Ricky Clarkson suggested using Haskell’s approach of allowing anything that is of the “Num” type to define +,-,/,*, etc…. I have a few things to add to this discussion.

Aviad’s idea for operators by interface is not a bad one; it works well for overloading “[]” but it breaks down on a few use cases (such as ‘+’, ‘*’, etc..) that are important (to me). Ricky’s idea for subtypes of a specific class getting to have operator overloading isn’t bad either, but for physical unit manipulation it is too inflexible. The core concept that both of them seem to have suggest is that a limited selection of types can have overloaded operators, but the operations that are possible aren’t limited to the scalar quantities that this would limit the operators to.

Suppose I have the classes Distance, Area, and the built-in “Scalar” type Double I would expect at least these sets of operations:
Distance * Distance => Area
Distance * Double => Distance

If I had to implement the Multipliable<T> interface, I wouldn’t be able to handle Distance * Distance and Distance * Double. You can’t implement an interface twice, even with different type parameters. I don’t know if this is something that Reified generics would fix, but it feels like it might be. Maybe someone could comment on that.

Also, if Distance had to extend Number, what would doubleValue return? Meters? Inches? Smoots? There might be some way to solve these problems, but I can’t think of a way to prevent abuse while allow good use.

Actually, now that I have thought a little about it…

The semantics of plus (+), minus (-), times (*), dividedBy (/), moduloOf (%), shiftLeft(<<), shiftRight(>>), unsignedShiftRight(>>>), or(|), and(&), xor (^), negative(-), and inverse(~), are all well-defined enough for so many not-necessarily-numeric types that allowing, even if only through naming conventions, the overloading of those operations seems like a good idea.

I think a good way to go would be to convert at compile time a * b to the method call a.times(b). Assignment operators like a += b would be replaced with a = a.plus(b). This would help reduce abuse while creating a more expressive language. The assignment operator rule is important, as it will help prevent the “clever” idiom of using += for appending elements to a collection.

Note on updates: I previously misspelled Aviad as “Avaid”. I also have added clarification for which use-cases Aviad’s Indexer doesn’t work for me, namely for algebraic operators.

While often times if (x instanceof Y) indicates a problem that should be solved with proper use of polymorphic methods, it sometimes is unavoidable (.equals(Object o) implementation for example). A common idiom is:

if (x instanceof Y) {
  Y y = (Y) x;
}

Of course, this makes sense from a utility point of view, you know that it is a Y object, and so you want Y functionality from it. From a programmers point of view though, it is terribly redundant in many ways. In many cases, static analysis can tell the compiler that when you are in the block of that if statement, that x is indeed a Y object, why then should I be forced to cast to Y? Why can’t the compiler figure out the type for me?

This becomes even more useful if we combine the concept with the fully useful Type Intersection (Not yet implemented). If both of these features were implemented, then you could write something like:

public <T extends Comparable<T>> void sort(List<? extends T> list) {
 if (list instanceof RandomAccess) {
    /* list compile-time type here would be List<? extends T>&RandomAccess. */
    sort(list);
  } else {
    /* Other type of sort implementation. */
  }
}
public <T extends Comparable<T>> void sort(List<? extends T>&RandomAccess list) {
  /* Random access sort implementation */
}

This type of static analysis feature could be extended to predict NPE’s and redundant checks. Heck, the IDE I use tells me when I’ve accessed something when it might be null, or when my inner-if statement is a subset of the outer. It even has shortcuts for adding the cast in the if (x instanceof Y) {} blocks.

First, for my subscribers that celebrate it, Happy Thanksgiving!

I’ve written about it before, but I think its worth revisiting. Type intersection would be a highly useful feature if not for one thing. “It is not possible to write an intersection type directly as part of a program; no syntax supports this.” - JLS (§4.9). That seems like a poor excuse to not support a feature as potentially powerful as type intersection could have been.

They were bold enough to add syntax all over the place for Generics. They added new syntatical meanings for ‘?’ ‘<’, and ‘>’. As a matter of fact, they added a syntax within that construct for handling Type Intersections. Would it really be that difficult to reuse that syntax outside of capture conversions and type inference? Heck, maybe even make it reifiable, although that’s not *as* important.

One example others have used in the past where it would be useful to have this type intersection is with the marker interface RandomAccess. While marker interfaces are less useful now that we have annotations, it none-the-less exists, and can be useful for ensuring that the user of an algorithm passes in a compatible list.

For example, its quite possible to do the following, even with the currently crippled implementation of type intersection.
<T extends List<String> & RandomAccess> void foo(T list) { ... }
You know that you’re getting a random access list. The pain point is that you can not do the following:
<T extends List<String> & RandomAccess> T foo() { return new ArrayList<String>(); }
The reason that isn’t legal is quite simple, even if its not obvious. T is any type that satisfies List<String>&RandomAccess, so you don’t know that it is an ArrayList. You might have MyNonArrayList<String> list = foo(); Oops, that would be an incompatible assignment.

The better approach would be to have the return type be an explicit type that is List<String>&RandomAccess. As a matter of fact, my suggestion is to use that syntax exactly, unless there is a compiler-grammar reason not to. So, our T foo() line becomes:
List<String>&RandomAccess foo() { return new ArrayList<String>(); }
So then we can do: List<String>&RandomAccess list = foo(); Actually, we could just use List<String> list=foo() if we don’t care about RandomAccess.

An important addition to make to this would be casting. For legacy support, if I have a List<String>, but I know that it should be an ArrayList (or some other RandomAccess), I should be able to cast: foo((List<String>&RandomAccess)list);

Last week I discussed some of the techniques for and benefits of not using simple “Primitive” values to represent your data. This article is all about taking that concept to the next level.

Let’s say that I have a value that represents an angle. I could use a double to represent the radians, or I could create a class called Angle, which internally might use a double to represent radians. If you are trying to avoid primitive obsession, you would use the latter. Now you have value objects of type Angle which can be used in meaningful ways. So, we’re done, right? I say no.

Angle is now its own form of primitive. Just as an Integer object is an abstraction of a numeric value in a specific set of reals, an Angle instance is an abstraction of a geometric/trigonometric angle. This means that it can be the building block for other more specific types. For instance, a 2 dimensional vector can be represented in “polar form” as an Angle and a Magnitude. In a physical simulation, a Magnitude is often a Distance, so we’ll assume that case for this article.

So, we can create a Vector interface (not to be confused with the java.util.Vector class). We can then create a PolarVectorImpl class which uses Angle and Distance. We can even create a CartesianVectorImpl which uses two Distance objects to represent the vector. Whats more, is these can both be used by anything that expects a Vector, with no extra work in the client code. We can easily create a rotate(Angle) method, or any other useful methods.

Another important and related concept that we haven’t touched on is mutability. If an object is mutable, that means that the apparent state of the object can change over the lifetime of the object. If an object is immutable, the apparent state of the object will appear the same throughout the lifetime of the object. This means that any invocation of one method on that object will always have the same outcome as any other on that same method. Also, any object that is returned from those methods must either be immutable themselves, or be distinct instances. Why is this important? Immutable objects have some benefits.

• Immutable objects are inherently thread safe.
• Immutable objects are easy to reason about.
• Immutable objects are easier to debug.
• Immutable objects can be passed around freely without defensive copying.

On the down side, immutability makes a pretty boring universe. If you’re object is expected to do different things depending on what has happened to it in the past, that object must be mutable. It must have state.

What does this have to do with primitive values? Its common to create immutable value objects. If we design the Angle class to be immutable, then we can safely say that one instance represents exactly one angle throughout its lifetime. All of our Angle objects are value objects. They are utility objects and reusable in many projects. On the other hand, if we’re doing a simulation of sorts, it might be useful to have a mutable angle, something that we can adjust over time. Lets call this class Heading. What’s in a Heading? An Angle, of course. Now here’s where things get interesting…

Since an Angle is a measurable thing, its easy to compare two values for equality. For Angles specifically, they are equal if their values represent the same geometric angle. Once equality is established, those objects are equal for ever. Not so with Heading. A Heading may represent the same angle at one moment in time, but at another moment they represent very different angles. For this type of object, equality only makes sense for the identity. A Heading instance is its own object, and can be queried/manipulated by many other objects/methods within the project.

The benefit of this design, is a manipulator/querier need not know who “owns” the Heading instance. A Robot might have a Heading, and a SteeringServo might manipulate that Heading. You can create the Robot and the SteeringServo objects independently of each other. The SteeringServo doesn’t even need to know its the Heading of a Robot. Once the Robot and SteeringServo both have the same Heading instance, they become connected without being coupled. This is huge goal for Object Oriented designers/programmers. The correct functioning of a SteeringServo isn’t dependent on the correct functioning of a Robot, or even of a Heading, only on itself. Similarly, a Robot’s correct functioning isn’t dependent on the correct functioning of the SteeringServo. The program as a whole may not work if there is a bug, but it easier to look at one class and ask yourself “Is there anything wrong with this code,” than it is to ask the same question about the whole project.

If you think all of this abstraction is unnecessary or unhelpful, think about all the layers beneath our Heading class. Lets have some fun and break it down into its most primitive parts.

• Heading instance is an identity value containing an Angle and representing a direction at a point in time.
• An Angle is an equal-comparable value containing a double and representing a direction.
• A double is a equal-comparable and order-comparable value containing an ordered set of bits and representing a real number.
• A bit is an equal-comparable value containing a memory cell representing true or false.
• A memory cell is often times a capacitor that is either charged or uncharged

If you had to think about the implementation details of a bit every time you used a double, it would make the mental weight of programming so immense that no useful programs could be written. Heading can now be used very easily without adding the mental weight of how its implemented. SteeringServo can be implemented without the mental weight of what it is steering. Overall, the practice of this kind of decoupling will make your program easier for the most important source-code interpreter. You.

Particularly (but not just) programmers who have a background in C tend to think of simple data as primitive data. Measurements are one of the simplest types of data, so why not do something like this:

public class Bob {
  double distance;
  double duration;
  double weight;
  /* ... rest of code which handles calculation based on distance,
          duration, and volume, based on some predefined units for each. */
}

While there isn’t anything broken about this code, it needlessly couples the algorithms used in Bob with the units used to express distance, duration, and weight. A more robust design would give each of these there own types, which could be unit-independent. We’ll deal with just Distance. I’ve decided to implement the Distance class use meters as its underlying representation, but this fact is hidden from all clients of the class. Furthermore, I’ve tried hide that fact from as many internal methods as possible.

public final class Distance {
    private final double meters;

    private  Distance(double meters) {
        this.meters = meters;
    }

    public double getMeters() {
        return meters;
    }

    public static Distance fromMeters(double meters) {
        return new Distance(meters);
    }

    public Distance times(double scalar) {
        return fromMeters(getMeters()*scalar);
    }

    public Area times(Distance distance) {
        return Area.fromSquareMeters(getMeters() * distance.getMeters());
    }

    public Distance plus(Distance distance) {
        return fromMeters(getMeters() + distance.getMeters());
    }
}

So, what do we have here? Distance now has methods that give you more meaningful operations. A Distance multiplied by another Distance is specifically an Area, but a Distances multiplied by a scalar (simple number), is just a scaled Distance. You can’t add an arbitrary scalar to Distance on accident.

If we were using simple double distance and used the convention that distances was measured in meters, we might see code like distance+=3; // add three meters Unfortunately, if we switch to a different metric, we just broke that line. Using the non-primitive Distance, the same line would be distance = Distance.plus(Distance.fromMeters(3)); Now, no one is constrained to use meters. We could easily add fromInches, getInches, fromYards, getMicrons, etc… We could also decide change the internal representation of Distance to use BobUnits (3.14 Bob Units is one Meter ), and no client code need be touched!

Another useful example are measurements which usually have other associated values with them. For example, Angles. Angles can be measured in Degrees, Radians, and many other units. They also have associated sine, cosine, tangent. So, lets take a look at an Angle class:

public final class Angle {
    private final double radians;

    private Angle(double radians) {
        this.radians = radians;
    }

    public double cosine() {
        return Math.cos(getRadians());
    }

    public double sine() {
        return Math.sin(getRadians());
    }

    public static Angle fromCartesian(Distance x, Distance y) {
        return fromRadians(Math.atan2(y.getMeters(), x.getMeters()));
    }

    public static Angle fromRadians(double radians) {
        return new Angle(radians);
    }

    public Angle plus(Angle angle) {
        return fromRadians(getRadians() + angle.getRadians());
    }

    public double getRadians() {
        return radians;
    }
}

Again, we arbitrarily choose radians as the implementations unit, and again we don’t expose this to the client, and we don’t rely on it internally unless we have to. We have an Angle plus an Angle is an Angle. We also have a way to get an angle from a Cartesian coordinate.
What’s more, we have sine() and cosine(). That’s the big deal with Angle! Now our clients don’t need to use ugliness such as “Math.cos(angle * degreeToRadians)”. If they have an Angle, they can get the sin, cos, degrees, radians, etc… Without having to know the details of the underlying units.

Now, any of these can be turned into interfaces or abstract classes, and then you could have different implementations based on the system needs. For instance, if you’re dealing with subatomic measurements, meters doesn’t make sense for distances, and seconds doesn’t make sense for durations. You could have a MicronDistanceImpl implementation of Distance, and NanosecondDurationImpl implementation of Duration. Similarly for a cosmic simulation, you could have light-years for Distance and millennia for Duration.

Oh, almost forgot. This also gives you the ability to have nice toString() representations. I haven’t added those to the above classes, but I could imagine the toString printing “12.0 meters” and “32.6 degrees”. This will help when presenting these values to a user as well.

This kind of abstraction is what makes good design. Next time you declare something as a primitive (or a dumb primitive wrapper such as Double, or Integer), think about what type units you might assign to it. You’ll find that your classes become simpler as well, since they don’t get bogged down in the formulas needed to convert between units. It also gives you much more expressive power. Think of a Speed class which has Distance and Duration fields. Maybe even a method on Distance public Speed divide(Duration duration);

When the Java people introduced enums, they went out of their way to support the switch statement with enums. Good OO design tends to avoid switches and instead use polymorphism to “decide” on behavior. While you can switch on enums, you also can add behavior to enums. As a matter of fact, this is useful for the flyweight pattern.

First, for those who don’t know, a Flyweight is a stateless object that represents some behavior for a set of other objects. For example, if you had to have an ‘e’ Glyph”object for every letter ‘e’ in this article, you’d have a lot of instances of the e glyph object. Using a flyweight, you have one instance of the ‘e’ Glyph, and whenever you need to evoke the behavior, you pass in the “state” (eg. the position on the screen) to the appropriate method.

For small sets of Flyweights, where the difference between any two instances is mostly behaviorally, enums are very useful. They wouldn’t be so useful for the ‘e’ Glyph example, since we’d have to write an enum with every character we wished to support. Glyphs also mostly differs in the shape, which can be broken down into data rather than behavior.

So, for our example, we’ll be using a Flyweight to mimic animals. Lets start out with our different types of animals.

public enum AnimalType {
    Cow,
    Chicken,
    Pig,
    Lion
}

Now, if we wanted to have an Animal class. Lets assume that we have an “World” class that contains information about our animal’s world. Including food sources and animal position, etc…

public final class Animal {
   private final AnimalType type;
   private final World world = World.getWorld();
   private int hungerLevel;
   public Animal(AnimalType type) {
      this.type = type;
   }
}

Now, objects aren’t generally useful unless they have behavior. We’re going to add simple delegation from the Animal class to its AnimalType instance.

public final class Animal {
   private final AnimalType type;
   private final World world = World.getWorld();
   private int hungerLevel;
   private int restLevel;
   public Animal(AnimalType type) {
      this.type = type;
   }

   public void eatFood() { type.eatFood(this);}

   public void sleep() {
     type.sleep(this);
   }

   public World world() { return world; }
}

public enum AnimalType {
    Cow {
        public void eatFood(Animal animal) {
            animal.world().findGrass().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findBarn().sleptInBy(animal);
        }
    },
    Chicken{
        public void eatFood(Animal animal) {
            animal.world().findCorn().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findCoop().sleptInBy(animal);
        }
    },
    Pig{
        public void eatFood(Animal animal) {
            animal.world().findTrough().getContents().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findBarn().sleptInBy(animal);
        }
    },
    Lion {
        public void eatFood(Animal animal) {
            animal.world().findPrey().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findSavana().sleptInBy(animal);
        }
    },
;
    public abstract void eatFood(Animal animal);
    public abstract void sleep(Animal animal);
}

So, as you can see, each animal has its own behavior. This particular flyweight implements the Strategy pattern for both eatFood() and sleep().

There have been a few discussions on how to do a particular task with the smallest amount of “code”. Some people talk about this with regards to soure code, and others with regards to object (a.k.a machine-instructions or byte code). While the later has some actual application, its often more “fun” to talk about the former.

Shrinking source code down for no other reason is generally bad practice, but it is an interesting exercise. I think that in this article we can distill the basic concept down to what is the smallest valid (in characters) Java source file that will compile, and when run does absolutely nothing.

For our first attempt, lets try the straight-forward approach. Not bending any rules.

class C{public static void main(String[]a){}}

That is 45 characters long. This compiles (javac C.java) and executes (java C) .Nothing spectacular, and there doesn’t appear to be anything superfluous there, but I assure you there is.

Think back to the JLS. Specifically, before the JVM can execute main() on a class, it must initialize it first (JLS 12.4.1).This gives use another way to execute code.

class C{static {} public static void main(String[]a){}}

This is a little longer, but bear with me. It still compiles and executes, just like our previous versions. What about removing main now?

class C{static{}}

This is indeed very short, and compiles just fine, but unfortunately we get Exception in thread “main” java.lang.NoSuchMethodError: main. Well, that doesn’t exactly do nothing, which is what our goal is. Note that we can put code into the static initializer.

class C{static{System.exit(0);}}

Now we’re down to 32 characters, and it compiles and does nothing. Sweet. What happens is that the JVM executes the static initializer before looking for the main method. The initializer tells the JVM to terminate (JLS 12.8), so it complies. Hence, no exception.

Is there anything else we can rid ourselves of? With the advent of Enums in Java 5, the answer is yes! We don’t need to explicitly create a static initializer, because enums will do that for us.

enum C{A;{System.exit(0);}}

27 charecters long, and it compiles and does nothing. Amazing. So what’s happening here? Enum types in Java are actually classes. Furthermore, they are singletons. In this case, the compiler creates two classes. C extends Enum, and A extends C. When we run java C, the JVM loads the class C which has a static initializer that sets C.A = new A(), which starts the instance initialization (JLS 12.5) process. Part of this process is to call the initializer of the parent class (in this case C). We added an instance initializer in C which kills the JVM.

So there you have it. The smallest possible Java program which does absolutely nothing (as far as I know). When trying to create the smallest possible Java program which does something, you would probably be wise to start from this template, unless you find a tricky way of having existing library code closing the JVM after doing your bidding otherwise. Not terribly useful, but somewhat entertaining, and it might help give you a better understanding of what goes on under the hood.

As with most of my esoteric Java features, don’t try this in production code.