Criticism of Java
From Wikipedia, the free encyclopedia
 |
This article's introduction section may not adequately summarize its contents. To comply with Wikipedia's lead section guidelines, please consider expanding the lead to provide an accessible overview of the article's key points. (March 2009) |
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.
Contents |
[edit] Language choices
[edit] 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.[1][2]
[edit] 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]
[edit] 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.[4][5]
[edit] Look and feel
 |
This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. (August 2008) |
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).
[edit] Performance
Java's performance has improved substantially since the early versions. Performance of JIT compilers relative to native compilers has in some tests been shown to be quite similar.[6][7][8]
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.[9] Sun Microsystems have taken considerable trouble to address these problems, and regularly produce white papers on this topic.[10] A more recent study (2003–4) gives Java a comparable performance to C++.[11] However, the validity of this study is disputed. [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 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.
[edit] See also
[edit] Notes
- ^ "Generics in Java". Object Computing, Inc.. http://www.ociweb.com/jnb/jnbJul2003.html. Retrieved on 2006-12-09.
- ^ "What's Wrong With Java: Type Erasure". 2006-12-06. http://www.safalra.com/programming/java/wrong-type-erasure/. Retrieved on 2006-12-09.
- ^ Java and unsigned integers
- ^ 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 on 2006-12-09.
- ^ "Types, Values, and Variables". Sun Microsystems. http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3. Retrieved on 2006-12-09.
- ^ Performance of Java versus C++, J.P.Lewis and Ulrich Neumann, Computer Graphics and Immersive Technology Lab, University of Southern California
- ^ The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
- ^ FreeTTS - A Performance Case Study, Willie Walker, Paul Lamere, Philip Kwok
- ^ Lutz Prechelt. Technical opinion: comparing Java vs. C/C++ efficiency differences to interpersonal differences. Communications of the ACM, Vol 42, #10, 1999
- ^ "Java SE 6 Performance White Paper". http://java.sun.com/performance/reference/whitepapers/6_performance.html.
- ^ "Benchmarks". http://scribblethink.org/Computer/javaCbenchmark.html.
- ^ "Java vs C++". http://www.freewebs.com/godaves/javabench_revisited/.
[edit] 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 Criticism
|
|||||||||||||||||||||||||
