Criticism of Java

From Seo Wiki - Search Engine Optimization and Programming Languages

Jump to: navigation, search

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


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
        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.[4]

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.[5]

Missing Features

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


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

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

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.[10][11]


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

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.[15] Sun Microsystems have taken considerable trouble to address these problems, and regularly produce white papers on this topic.[16] A more recent study (2003–4) gives Java a comparable performance to C++.[17] However, the validity of this study is disputed.[18]

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


  1. "Generics in Java". Object Computing, Inc.. Retrieved 2006-12-09. 
  2. "What's Wrong With Java: Type Erasure". 2006-12-06. Retrieved 2006-12-09. 
  3. "Type Erasure". 
  4. "Java Generics FAQs - Under The Hood Of The Compiler". 
  5. Java and unsigned integers
  10. Kahan, W.; Joseph D. Darcy (1998-03-01). "How Java's Floating-Point Hurts Everyone Everywhere" (PDF). Retrieved 2006-12-09. 
  11. "Types, Values, and Variables". Sun Microsystems. Retrieved 2006-12-09. 
  12. 12.0 12.1 J.P.Lewis and Ulrich Neumann. "Performance of Java versus C++". Graphics and Immersive Technology Lab, University of Southern California. 
  13. The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
  14. FreeTTS - A Performance Case Study, Willie Walker, Paul Lamere, Philip Kwok
  15. Prechelt, Lutz (October 1999). "Technical opinion: comparing Java vs. C/C++ efficiency differences to interpersonal differences". Communications of the ACM 42 (10). 
  16. "Java SE 6 Performance White Paper". 
  17. "Benchmarks". 
  18. "Java vs C++". 

External links

Template:Java (Sun)ja:Javaに対する批判

Personal tools

Served in 0.529 secs.