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 security vulnerabilities. Additionally, Java, especially its early versions, has been criticized for its performance compared to other programming languages. Many^[who?] 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 all but the most trivial of 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.^[1][2]

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

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.^[4] 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, a 32-bit unsigned value would require a 64bit signed integer, and a 64bit unsigned value cannot be stored using any integer type in Java because no type larger than 64 bits exists in the Java language. In all cases, the memory consumed is doubled, 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.^[5]

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.^[6][7][8]

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

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

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 far more targeted than Acrobat or Flash.^{[13][dubious – discuss]Microsoft publication} This targeting appears to be tied to high numbers of computers with Java installed and the high percentage of computers that have not been updated with Java security updates.^{[original research?]}

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.^[13][14]

Among the suggestions made by critics is that users should consider uninstalling Java given the security risk and given the limited number of web sites that require Java to be installed on the browser's computer.^[15]

See also

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

Notes

1. ^ "Generics in Java". Object Computing, Inc.. http://www.ociweb.com/jnb/jnbJul2003.html. Retrieved 2006-12-09. 
2. ^ "What's Wrong With Java: Type Erasure". 2006-12-06. http://www.safalra.com/programming/java/wrong-type-erasure/. Retrieved 2006-12-09. 
3. ^ "Type Erasure". http://java.sun.com/docs/books/tutorial/java/generics/erasure.html. 
4. ^ "Java libraries should provide support for unsigned integer arithmetic". Bug Database, Sun Developer Network. Oracle. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4504839. Retrieved 2011-1-18. 
5. ^ Owen, Sean R. (2009-11-05). Java and unsigned integers "Java and unsigned int, unsigned short, unsigned byte, unsigned long, etc. (Or rather, the lack thereof)". http://darksleep.com/player/JavaAndUnsignedTypes.html Java and unsigned integers. Retrieved 2010-10-09. 
6. ^ Kahan, W.; Joseph D. Darcy (1998-03-01). "How Java's Floating-Point Hurts Everyone Everywhere" (PDF). http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf. Retrieved 2006-12-09. 
7. ^ "Types, Values, and Variables". Sun Microsystems. http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3. Retrieved 2006-12-09. 
8. ^ "Java theory and practice: Where's your point? Tricks and traps with floating point and decimal numbers". IBM. 2003-1-1. http://www.ibm.com/developerworks/java/library/j-jtp0114/. Retrieved 2011-11-19. 
9. ^ "Computer Language Benchmarks Game: Java vs Gnu C++". Debian.org. http://shootout.alioth.debian.org/u64q/java.php. Retrieved 2011-11-19. 
10. ^ ^{a b} J.P.Lewis and Ulrich Neumann. "Performance of Java versus C++". Graphics and Immersive Technology Lab, University of Southern California. http://scribblethink.org/Computer/javaCbenchmark.html. 
11. ^ The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
12. ^ FreeTTS - A Performance Case Study, Willie Walker, Paul Lamere, Philip Kwok
13. ^ ^{a b} "Researchers Highlight Recent Uptick in Java Security Exploits". http://www.infoq.com/news/2010/10/java-exploit-uptick. 
14. ^ "Have you checked the Java?". http://blogs.technet.com/b/mmpc/archive/2010/10/18/have-you-checked-the-java.aspx. 
15. ^ "Java: A Gift to Exploit Pack Makers". http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/. 

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)