Criticism of 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 type 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 common template parameter E 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
    }
}

By design, Java encourages programmers to think of a programming solution in terms of nouns (classes) interacting with each other, and to think of verbs (methods) as operations that can be performed on or by that noun.[5] Steve Yegge argues that this causes an unnecessary restriction on language expressiveness because a class can have multiple functions that operate on it, but a function is bound to a class and can never operate on multiple types.[6]

In many other multi-paradigm languages, there is support for functions as a top-level construct. When combined with other language features such as function overloading (one verb, multiple nouns) and/or generic functions (one verb, a family of nouns with certain properties), the programmer is given the ability to decide whether it makes more sense to solve a specific problem in terms of nouns or verbs. Java version 8 introduced some functional programming features.

In 2008 the U.S. DOD's Center Software Technology Support published in the "Journal of Defense Software Engineering" an article discussing the unsuitableness of Java as first learned programming language in education. Disadvantages given for Java as first language were that students "had no feeling for the relationship between the source program and what the hardware would actually do" and the impossibility "to develop a sense of the run-time cost of what is written because it is extremely hard to know what any method call will eventually execute".[7] Similarly Joel Spolsky in 2005, criticised Java as overfocused part of universities' curriculum in his essay The Perils of JavaSchools.[8] Others, like Ned Batchelder, disagree with Spolsky for criticizing the parts of the language that he found difficult to understand, claiming that Spolsky's commentary was more of a 'subjective rant'.[9]

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.[10] 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 bitwise operations.[11] Some support for unsigned integer types was provided in JDK 8, but not for unsigned bytes and with no support in the Java language.[12]

Java has been criticized for not supporting the capability of implementing user-defined operators. Operator overloading improves readability,[13] thus the lack of it in Java can make the code less readable, especially for classes representing mathematical objects, such as complex numbers, matrices, etc. The language contains only one non-numerical usage for operators, and that is String concatenation, implemented with the + operator. However, this is implemented only in the compiler, and compiles to a StringBuilder - it is impossible to create user-defined operator overloads.

Java lacks compound value types, such as structs in 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.[14][15][16] A typical example is Java's HashMap, which is internally implemented as an array of HashMap.Entry objects.[17] 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.

Java has been criticized for not supporting arrays of more than 2³¹−1 (about 2.1 billion) elements.[18][19][20] 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.[21]

Supporting large arrays would also require changes to the JVM.[22] This limitation manifests itself in areas such as collections being limited to 2 billion elements[23] and the inability to memory map continuous file segments larger than 2 GB.[24] 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.[15]

There is no efficient way to initialize arrays in Java. When declaring an array, the JVM compiles it to bytecodes with instructions that set its elements one by one at runtime. Because Java methods cannot be bigger than 64KB, arrays of even modest sizes with values assigned directly in the code will throw the message "Error: code too large" on compilation.[25]

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

Per Brinch Hansen argued in 1999[27] that Java's implementation of parallelism in general and monitors in particular do not provide the guarantees and enforcements required for secure and reliable parallel programming. While it is possible for a programmer to establish design and coding conventions to, say, only access thread-global variables in a controlled fashion, the language and compiler make no attempt to enforce that controlled access. I.e. the programmer may mistakenly allow uncontrolled access to thread-global variables, and the compiler will not detect it.

Java provides a mechanism, called object serialization where an object can be represented as a sequence of bytes that includes the object's data as well as information about the object's type and the types of data stored in the object. After a serialized object has been written into a file, it can be read from the file and deserialized that is, the type information and bytes that represent the object and its data can be used to recreate the object in memory[28] This poses very serious theoretical and actual security risks.[29][30]

With Java versions prior to 7, it was normal for the installer not to detect or remove prior Java installations. It was quite common on a Windows computer to see multiple installations of Java 6 on the same computer, varying only by update revision. Multiple Javas are permitted and can be accessed by programs that look for specific versions.

This has the effect that new Java installations only provide new language features and bug fixes, but they do not correct security vulnerabilities, because malicious programs can look for the older prior Java releases and use them rather than the newest versions.

Java 7 updated prior versions of itself, but did not look for the presence of Java 6 and earlier.[45]

As of 2014, common 3rd party tools (such as Adobe Flash and Adobe Reader) that have been the subject of security vulnerability scrutiny, have moved to an automatic update model on Windows. This model doesn't require any user intervention, and assures that security issues are promptly resolved without requiring additional effort by the system users or administrators.

As of 2015, Java 8 still requires that the computer user manually apply Java updates themselves. These updates can only be applied by those with administrator privileges. The Windows Java updater frequently triggers a disruptive random User Account Control elevation prompt; however, choosing Yes or No for elevation will still yield the same "Java needs to be updated" message.