Criticism of Java

A number of criticisms have been leveled at Java programming language for various design choices in the language and platform. Such criticisms include the implementation of generics, the handling of unsigned numbers, the implementation of floating-point arithmetic, and a history of security vulnerabilities. Additionally, Java, especially its early versions, has been criticized for its performance compared to other programming languages. Developers have adapted Sun's phrase of "write once, run everywhere" to "write once, debug everywhere" in reference to the numerous differences in underlying platform which still must be taken into account when writing complex Java programs.

Language syntax and semantics

Generics

Further information: Generics in Java

When generics were added to Java 5.0, there was already a large framework of classes (many of which were already deprecated), so generics were chosen to be implemented using erasure to allow for migration compatibility and re-use of these existing classes. This limited the features that could be provided by this addition as compared to other languages.

Because generics were implemented using type erasure the actual type of a template parameter is unavailable at runtime. Thus, the following operations are not possible in java:

public class MyClass<E> {
    public static void myMethod(Object item) {
        if (item instanceof E) {  //Compiler error
            ...
        }
        E item2 = new E();   //Compiler error
        E[] iArray = new E[10]; //Compiler error
    }
}

Unsigned integer types

Java lacks native unsigned integer types. Unsigned data is often generated from programs written in C and the lack of these types prevents direct data interchange between C and Java. Unsigned large numbers are also used in a number of numeric processing fields, including cryptography, which can make Java more inconvenient to use for these tasks. Although it is possible to partially circumvent this problem with conversion code and using larger data types, it makes using Java cumbersome for handling unsigned data. While a 32-bit signed integer may be used to hold a 16-bit unsigned value losslessly and a 32-bit unsigned value would require a 64-bit signed integer, a 64-bit unsigned value cannot be stored easily using any integer type because no type larger than 64 bits exists in the Java language. In all cases, the memory consumed is doubled (This is only partially correct, since Java internally uses either 32- or 64-bit storage for shorter primitive types such as byte (8 bits), short (16 bits), boolean (1 bit)), and any logic that depends on the rules of two's complement overflow must typically be rewritten. If abstracted using functions, function calls become necessary for many operations which are native to some other languages. Alternatively, it is possible to use Java's signed integers to emulate unsigned integers of the same size, but this requires detailed knowledge of complex bitwise operations.

Floating point arithmetic

While Java's floating point arithmetic is largely based on IEEE 754 (Standard for Binary Floating-Point Arithmetic), certain features are not supported even when using the strictfp modifier, such as Exception Flags and Directed Roundings — capabilities mandated by IEEE Standard 754. Additionally, the extended precision floating-point types permitted in 754 and present in many processors are not permitted in Java.

Performance

Further information: Java performance

In the early days of Java (before the HotSpot VM was implemented in Java 1.3 in 2000) there were many criticisms of performance. Java has been demonstrated to run at a speed comparable with optimised native code, and modern JVM implementations are regularly benchmarked as one of the fastest language platforms available -- typically within a factor of 3 relative to C/C++.

Java's performance has improved substantially since the early versions. Performance of JIT compilers relative to native compilers has in some optimized tests been shown to be quite similar.

Java bytecode can either be interpreted at run time by a virtual machine, or it can be compiled at load time or runtime into native code which runs directly on the computer's hardware. Interpretation is slower than native execution, and compilation at load time or runtime has an initial performance penalty for the compilation. Modern performance JVM implementations all use the compilation approach, so after the initial startup time the performance is equivalent to native code.

Security

Adobe Acrobat and Adobe Flash are among the most targeted software for security exploits. In 2010, targeting of Java security exploits increased significantly, resulting in Java becoming a common target. Often long-known security holes in the Java virtual machine is targeted. This is tied to high numbers of computers with Java installed and the high percentage of computers that have not been updated with Java security updates.

Critics have suggested that updated versions of Java are not used because there is a lack of awareness by many users that Java is installed, there is a lack of awareness of many users of how to update Java, and (on corporate computers) many companies restrict software installation and are slow to deploy updates.

See also

• Comparison of Java and C++
• Comparison of Java and C#
• Comparison of the Java and .Net platforms
• Java performance

External links

• Free But Shackled - The Java Trap, an essay by Richard Stallman of the free software movement (dated April 12, 2004)
• Computer Science Education: Where Are the Software Engineers of Tomorrow? (dated January 8, 2008)