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  is the first introductory textbook; Java Software Solutions  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.
if'' problem is present in Java; most modern
languages have eliminated it. C's
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  provides a list of such features:
final. Variables that are local to a method cannot be declared
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
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  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.
© 1997 ACM