Criticism of Java

A number of criticisms have been leveled at Java programming language for various design choices in the language and platform, such as the introduction of generics, the types available for numeric variables, and the look-and-feel of its default toolkits.

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
        E obj = (E)new Object(); //Unchecked cast warning
    }
}

Another limitation is that primitive types cannot be used in generics; the workaround is using classes that wrap around a primitive type (though this may result in reduced performance).

"Unchecked" warnings as a result of cast expressions, and can usually be eliminated by eliminating the offensive casts. Unchecked warnings also occur when the compiler finds a cast whose target type is either a parameterized type or a type parameter. There are situations where a cast to a type parameter or a concrete or bounded wildcard parameterized type cannot be avoided. At runtime, only the type erasure is available, not the exact static type that is visible in the source code. As a result, the runtime part of the cast is performed based on the type erasure, not on the exact static type. The clone method and invocation of methods via reflection are two well-known cases where an "unchecked" warning is unavoidable (without resorting to using the @SuppressWarnings("unchecked") annotation.

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. Although it is possible to circumvent this problem with conversion code and using larger data types, it makes using Java cumbersome for handling unsigned data. If abstracted using functions, function calls become necessary for many operations which are native to some other languages.

Missing Features

Java lacks certain features that are considered by some to improve readability and/or programmer productivity.^{[citation needed]}

Closures

Closures (like functors) have been a hotly debated topic within the Java community. The main contenders have been:

• BGGA by Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahe
• CICE (Concise Instance Creation Expressions) by Bob Lee, Doug Lea, and Josh Bloch
• FCM (First Class Methods) by Stephen Colebourne and Stefan Schulz

Initially Sun announced that closures would not make it into Java 1.7, after a schedule extension, Principal Engineer Mark Reinhold (who works on Java SE and OpenJDK) announced at the Java community conference Devoxxthat they'd be included after all.

The current proposal is the subject of active discussion.

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. Many so-called "Java gotchas" are not problems with Java per se, but problems that are inevitable whenever using floating point arithmetic.

Performance

Further information: Java performance

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

In a paper written in 1999 by Lutz Prechelt, it is outlined that, statistically, programmer efficiency and experience has a bearing many standard deviations greater on run-time and memory usage than language choice. This paper specifically uses Java as a basis for the comparison, due to its then-bad reputation. Sun Microsystems have taken considerable trouble to address these problems, and regularly produce white papers on this topic. A more recent study (2003–4) gives Java a comparable performance to C++. However, the validity of this study is disputed.

Java bytecode can either be interpreted at run time by a virtual machine, or it can be compiled at load time or runtime into machine 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.

See also

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

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)
• Java Criticism