One of the most recent object-oriented languages is Java. This language was introduced for programming World-Wide Web applications, but is also useful in other areas, particularly for building portable graphical user interfaces. Java is now very popular, and will probably take over from C++ in many places. It is also easier to use than C++, avoiding many of the latter's design errors. However, we believe Java suffers from problems of its own, caused by its desire to treat everything as an object. This leads to code that is hard to read, and in this paper, we argue that Java's designers should have provided it with a means of defining non-object data types, particularly for mathematical entities such as numbers, vectors and lists. The language also needs a module construct for grouping together operations, both on objects and non-objects.
It is not only important that the language have these facilities, but that the programmer know when to use them. Many OOP programmers, whatever the language, try to force it to represent modules and non-object data types as objects. After displaying some of the symptoms resulting from Java's excessive attachment to objects, and explaining how the implementation causes them, we therefore present some criteria to help programmers decide which construct is most appropriate. Although we have applied them to Java, we have done so mainly to avoid having to explain lots of different languages; they are in fact generally applicable to any OOP language or design task.
In the rest of this paper, we assume familiarity with classes, instances, methods, and inheritance. We don't assume advanced knowledge of Java, though if you wish to read further Java in a Nutshell [Flanagan] is one of the best introductory references.