5. Disadvantages of Java
Like any programming language, Java is not without drawbacks. 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 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.
what about this............
also see this ...........
# 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.''
# 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.''
Labels:
u know?
