5. Disadvantages of Java

Like any programming language, Java is not without drawbacks. Section 2.8 mentioned one of them: Java is an interpreted language, so programs written in Java won't be speed demons. Still, for most programs that students write, speed is secondary. With ever-faster computers available at bargain prices, Java should be fast enough for all but the most time-intensive programs.

Other problems stem from Java's youth. For one thing, Java isn't available on all platforms. Although Java will likely spread to more as time goes on, it's unlikely to be implemented on older platforms. That will cause problems for institutions that lack funds for hardware and software upgrades. Still, that barrier should be only a temporary one.

Java is relatively immature. Although the language itself is unlikely to change dramatically, we can expect significant changes in the Java API and associated technology. (The latest version of the Java Development Kit, JDK 1.1, is currently in beta. It features a host of changes to the API.) Still, C++ has been in a state of almost continuous change since it was created--the official standard isn't expected for another year or two--but that hasn't stopped industry and academia from adopting it.

Java is also hampered by a shortage of genuine textbooks. This problem should also take care of itself within a short time. The tremendous sales of Java books in the trade market will undoubtedly spur publishers to make Java texts available as well. Java How to Program [4] is the first introductory textbook; Java Software Solutions [9] is due out in 1997.

The syntax of Java can be criticized. Making Java resemble C and C++ was a shrewd move on the part of Java's designers: the language looks familiar to most software developers, making it easy to switch to. On the other hand, Java has inherited some of the quirks and traps of C and C++. For example, the placement of semicolons can easily trip up the beginner. The ``dangling if'' problem is present in Java; most modern languages have eliminated it. C's /* ... */ comment style is supported, allowing students to accidentally ``comment out'' parts of their programs.

Another criticism of Java is that it lacks certain features that are desirable for teaching introductory courses. Hosch [5] provides a list of such features:

No separation of specification from implementation. Java classes aren't divided into specification and implementation parts. Hosch feels that this is an important point for beginners and would like ``this distinction between specification and implementation to be supported by the syntactic structure of the language.'' Lacking such a separation, he would at least like to be able to write prototypes for methods, which Java doesn't allow except within an abstract class or interface.
No preconditions and postconditions. Hosch's introductory course emphasizes preconditions and postconditions, for which he would like language support. Java, like most languages, has no such support. (Among major languages, only Eiffel does.)
Visibility rules are ``baroque.'' Hosch decries the many types of visibility in Java. He also laments that Java's syntactic support for hierarchical packages doesn't carry any semantic significance.
No support for genericity. Hosch notes Java's lack of support for writing generic data structures and methods. As a substitute, he would accept ``type by association,'' such as Eiffel's anchored types.
No enumeration types. Java lacks enumeration types entirely, although they can be simulated by creating a series of named constants.
No local constants. In Java, variables that belong to a class can be made constant by declaring them to be final. Variables that are local to a method cannot be declared final, however.
Exceptions not caught within a method must be declared as thrown by that method. Hosch finds this requirement to be onerous: ``for introductory students, it's a sequence of ugly, unintelligible syntactic marks.''

To some instructors these criticisms may be a major concern; to others they are likely to be minor quibbles. None of Hosch's complaints would dissuade me from using Java in an introductory class. In particular, his complaints about visibility and hierarchical packages seem to be of little consequence in an introductory course.

Hosch's criticism of exceptions appears to be based on a misunderstanding of this feature. Not all exceptions need to be declared as being thrown by a method. Many of the most common exceptions, including ArithmeticException, IndexOutOfBoundsException, and NullPointerException are exempt from this requirement. Only exceptions that the programmer should have handled but didn't are required to be declared as thrown by a method. This feature actually has a pedagogical advantage, since it enables the compiler to point out exceptions that students have overlooked.

Bergin [1] complains that Java lacks templates, overloaded operators, and user-defined conversions. The latter two, he points out, are useful for making a user-defined type behave like a built-in type. Like Hosch, he also laments the lack of separation between specification and implementation.

Next section

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.