In “Rethinking the Java Curriculum: Goodbye, Hello World!”, Daniel Steinberg talks about how non-OO current introductions to the highly object-oriented Java language are, and challenges us to come up with an alternative. I've taught a number of Introduction to Java courses, and I've long thought there must be a better way.

Update: Like all good ideas, it seems someone else has had this one first. Check out BlueJ for an example of pretty much exactly what I was talking about.

The way we teach Java to beginning programmers at the moment often does more harm than good. In a nutshell, the problems lie in two places—the need to produce fully running programs, and the consequent far-too-early introduction of the GUI.

Procedural and functional languages, you learned by starting with simple, command-line programs that calculated your biorhythms, your ideal weight, or how many cents you earn per minute. If you take the same approach with Java, you end up teaching all new Java programmers how to code procedurally. You then have to repair the damage you've caused, and shunt them painfully into the world of objects.

Java's command-line capabilities are also pretty dismal, so almost immediately, students are asked to write applets or stand-alone GUI components. GUI programming is difficult, and involves understanding a lot of concepts that students aren't even remotely comfortable with, so this is another thing that damages the student.

Working as a Java professional, I've noticed there are two things I almost never write: graphical user interfaces, and public static void main (String[] args). Almost all the code I write is in the form of objects that fit into some environment such as an application server. So how about we reflect that in beginners' classes?

Here's the first object a student should write:

public class Greeter {
    public String getGreeting() {
        return "Hello World!";
    }
}

Unlike public static void main (String args[]), this code-fragment immediately focuses the virgin programmer on the central concepts of Java—not program entry points, but the object and the method. Once they have written this, they can do the obvious next modification.

public class Greeter {
   private String name;

   public Greeter(String name) {
       this.name = name;
   }

   public String getGreeting() {
       return "Hello, " + name + "!";
   }
}

This moves us on to instance variables, constructors, and we can go on a quick tangent about the slightly weird + operator. And so on. From the outset, we build objects, not procedures, not programs. By the end of the day, we've written a simple, multi-function calculator object that doesn't do anything on its own, but can be used to perform any arithmetic operation we want.

But if we don't have a main method, how do we run anything? Simple. Think of a Smalltalk environment, or of those tools that use introspection to allow you to test arbitrary EJBs. Provide the students with a “learning environment” that allows them to test the behaviour of the objects they have just written by sending them messages, and viewing the results. The hot-swapping introduced in Java 1.4 would allow a certain degree of on-the-fly debugging and immediate “if I do this, it changes the behaviour like this” feedback.

Ideally, such an environment would let students create objects, inspect them, pass them around, maybe even step through code when necessary. The basic idea, though, is once again we're immersing the students directly into the real world of Java programming - thinking in terms of objects and messages, not procedures and short-lived programs.

It would also free the students from having to immediately dive into AWT. The learning environment would be fully graphical, allowing direct manipulation of objects, so the “create a button that sums the two numbers in the text fields” problem would no longer be a necessary evil of Java tutoring.

Eventually, eventually, you would introduce the students to ways of making objects work outside the learning environment. The time to do that would be after the students understood what “public”, “static”, “void” and “String[]” mean.