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 in the primary Java VM implementation HotSpot. Additionally, Java, especially its early versions, has been criticized for its performance compared to other programming languages. Developers have also remarked that differences in various Java implementations must be taken into account when writing complex Java programs that must be used across these implementations^[1]

Language syntax and semantics

Generics

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.^[2][3]

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:^[4]

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.^[5] 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 may increase by a factor of up to two, 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.^[6] Support for unsigned integer types will be provided in JDK 8.^[7]

Compound value types

Java lacks (compound) value types, such as structs in C/C++, bundles of data that are manipulated directly instead of indirectly via references. Value types can offer significant performance improvements and memory savings in some cases.^{[8] [9][10]} A typical example is Java's HashMap, which is internally implemented as an array of HashMap.Entry objects.^[11] Because Java lacks value types, this array is actually an array of references (pointers) to Entry objects, which in turn contains references to key and value objects. Looking up something in the map requires inefficient double indirection. If Entry were a value type, the array could store pairs of key and value references directly, eliminating the first indirection, increasing locality and reducing memory usage and heap fragmentation. If Java further supported generic primitive types, primitive keys and values could be stored in the array directly, removing the second indirection.

Large arrays

Java has been criticized for not supporting arrays of more than 2³¹ - 1 (about 2.1 billion) elements.^{[12][13] [14]} This is a limitation of the language; the Java Language Specification, Section 10.4, states that:

Arrays must be indexed by int values... An attempt to access an array component with a long index value results in a compile-time error.^[15]

Supporting large arrays would also require changes to the JVM.^[16] This limitation manifests itself in areas such as collections being limited to 2 billion elements^[17] and the inability to memory map files larger than 2 GB.^[18] Java also lacks true multidimensional arrays (contiguously allocated single blocks of memory accessed by a single indirection), which limits performance for scientific and technical computing.^[9]

Integration of primitives and arrays

The fact that arrays and primitives are somewhat special and need to be treated differently from (other) objects has been criticized,^[19] because it requires writing many variants when creating general libraries.

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.^[20][21][22]

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++.^[23]

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

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 similar to native code.

Security

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 are 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.^[27]

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.^[27][28]

Oracle has been criticised for not providing Java security updates for known security bugs, for long periods of time, despite these security bugs being exploited whilst unpatched.^[29]

Robustness

Lack of isolation

Java specification does not provide means for isolating users on server programs, or isolating tasks in general.^[30] Even scalable Java EE servers put about 100 users per JVM.^[31] If a user request allocates too much memory, the server engine can have its allocation requests denied and the entire JVM goes down, causing session losses or at least big performance penalties. It's also not safe to mix applications from distinct providers in the same Java EE server, since memory leaks or infinite loops can slowly degrade performance to the point that JVM halts or has to be killed.^[32]

This in part is caused by garbage collection and the threaded model which suits it more easily, versus address-space-isolated processes with shared memory segments. It is not impossible to run multiple JVM processes, each under their own credentials, but those must then communicate together when shared resources are needed, increasing complexity and potentially reducing performance.

Fix proposals

There are proposals to address these limitations, such as the cloneable JVM,^[33] the multi-tasking virtual machine,^[34] and the Application Isolation API.^[35] But none of them are part of Java SE up to version 7, and as of April, 2012, they are not in the roadmap for Java SE 8, 9 or 10.^[36]

See also

• Comparison of Java and C++
• Comparison of Java and C#
• Comparison of the Java and .Net platforms
• Java performance
• Write once, run anywhere

Notes

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 Java platform Java language JVM Micro Edition Standard Edition Enterprise Edition Java Card Sun technologies Squawk Java Development Kit OpenJDK Java virtual machine JavaFX Maxine VM Platform technologies Applets Servlets MIDlets jsp Web Start (jnlp) Major third-party technologies JRockit GNU Classpath Kaffe TopLink Apache Harmony Apache Struts Spring framework Hibernate JBoss application server Tapestry Jazelle History Java version history Java Community Process Sun Microsystems Free Java implementations Major programming languages BeanShell Clojure Groovy Oxygene Java Tcl JRuby Jython Processing Rhino Scala more… Java conferences JavaOne