Jump to content

Criticism of Java

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 63.78.121.8 (talk) at 20:59, 5 October 2009 (→Performance). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

A number of criticisms have been levelled 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 choices

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]

One of those resulting limits is that primitive types cannot be used in generics. The workaround is using classes that wrap around a primitive type. This method is a poor solution, because of a low performance after boxing and unboxing. Also it reduces memory cache efficiency because objects are allocated in different memory areas. Garbage collector has to look for every single element, instead of treating an array as one big object. That makes Java generics unusable for high performance computations.

Unsigned integer types

Java lacks native unsigned integer types which are very useful in some situations (i.e. dealing with binary data manipulation). Although it is possible to circumvent this problem with extra code and using larger data types, it makes using Java cumbersome for these tasks. If abstracted using functions, function calls become necessary for many operations which are native to some other languages.[3]

Altering of the execution order in the finally clause

While the finally construct itself is not problematic, altering of the execution order or returning to the calling method inside it can result to near unpredictable results. For instance, the construct 

 try {
  return 11;
 } finally {
  return 12;
 }

actually returns 12, not 11, but this is something not easy to predict. break inside finally can also be very confusing. The problem can be avoided by not using in finally statements that would alter execution flow outside this construct. The recent compilers issue warnings for such cases that can be configured to be treated as errors[4].

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

Look and feel

The look and feel of GUI applications written in Java using the Swing platform may look different from native applications. While programmers can choose to use the AWT toolkit that displays native widgets (and thus look like the operating platform), the AWT toolkit is unable to meet advanced GUI programming needs by wrapping around advanced widgets and not sacrificing portability across the various supported platforms, each of which have vastly different APIs especially for higher-level widgets. If an alternative GUI toolkit is used, such as SWT, it is possible for a Java application to have native look and feel whilst also having access to advanced widgets.

The Swing toolkit – written completely in Java – both creates the problem of having a different look and feel from native applications, and avoids the problem of being limited by native toolkit capabilities because it reimplements widgets using only the most basic drawing mechanisms that are guaranteed available on all platforms. Unfortunately, the default installations of the JRE (as of August 2006) do not use the system's "native" look and feel, instead defaulting to the built-in Metal Look and Feel. If the programmer doesn't take care to set the native look and feel, users will have applications whose appearance is vastly different from that of their native applications. Apple Computer's own optimized version of the Java Runtime, which is included within the Mac OS X distribution, by default does set the default and implements its "Aqua" look-and-feel, giving Swing applications on the Macintosh a similar appearance to native software. Even in this environment, the programmer must still do some extra work to ensure that that application looks like an Aqua one (for example, they must set system properties to ensure the menubar is rendered in the OS X menubar and not in the application window as it would be on other platforms).

Performance

Further information: Java performance

Java's performance has improved substantially since the early versions.[citation needed] Performance of JIT compilers relative to native compilers has in some tests been shown to be quite similar.[7][8][9]

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

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

Notes

  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. {{cite web}}: Check date values in: |date= (help)
  3. ^ Java and unsigned integers
  4. ^ http://www.eiffelroom.org/blog/manus_eiffel/and_people_are_still_using_java#comment-647
  5. ^ Kahan, W. (1998-03-01). "How Java's Floating-Point Hurts Everyone Everywhere" (PDF). Retrieved 2006-12-09. {{cite web}}: Check date values in: |date= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
  6. ^ "Types, Values, and Variables". Sun Microsystems. Retrieved 2006-12-09.
  7. ^ Performance of Java versus C++, J.P.Lewis and Ulrich Neumann, Computer Graphics and Immersive Technology Lab, University of Southern California
  8. ^ The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
  9. ^ FreeTTS - A Performance Case Study, Willie Walker, Paul Lamere, Philip Kwok
  10. ^ Lutz Prechelt. Technical opinion: comparing Java vs. C/C++ efficiency differences to interpersonal differences. Communications of the ACM, Vol 42, #10, 1999
  11. ^ "Java SE 6 Performance White Paper".
  12. ^ "Benchmarks".
  13. ^ "Java vs C++".
Retrieved from "https://en.wikipedia.org/w/index.php?title=Criticism_of_Java&oldid=318123674"