Criticism of Java

Java was intended to serve as a novel way to manage software complexity. Most consider Java technology to deliver reasonably well on this promise. However, Java is not without flaws, and it does not universally accommodate all programming styles, environments, or requirements.

Classpath

Installing the JRE requires explicitly setting the classpath and Java is unforgiving if you do it wrong. This confuses a lot of people new to Java. For instance,

• Classpath is platform specific when it comes directory names. Unix-based filesystems uses colons and slashes whereas Windows uses semicolons and backslashes.
• Any Jar file needed in the classpath must be individually added. Stating the path it is in is not enough.

License

Java's semi-proprietary nature gives it a controversial position in the open source community. Its availability on Linux and the open source licenses of many Java-based technologies such as Apache Tomcat and IBM-initiated Eclipse make Java more desirable to the open source community than Microsoft's platform specific and proprietary .NET Framework. However:

• Since it is not open source, it cannot be included in projects that require an open source license (such as Debian main and the $100 laptop).
• Some commentators [1] assert that Java SCSL license requires that anyone who agrees to the license terms waives their right to contribute to free software clean-room implementations of Java; however Sun spokespeople assert this is no longer an issue under revised Java licensing terms [2].
• Some observers believe that open sourcing Java would speed up implementing new technologies into Java and provide other benefits usually attributed to open source software .

Sun announced in JavaOne 2006 that Java will become Open Source. The statement was issued by Sun Software Executive Vice President Rich Green : "It's not a question of whether, it's a question of how, and so we'll go do this."[3] The point of contention with Sun is that they want to open source Java without facilitating an incompatible fork [4].

Memory management

Java takes care of memory management. This was done as it makes it harder (but not impossible) for the programmer to create problems such as memory leaks. However,

• Programmers who only know memory managed languages haven't necessarily learned the skills to deal with the situations when memory leaks do happen.
• Java automates where in memory objects (on the heap) and primitives (on the stack) are placed. This makes Java less flexible than C++ which allows programmers to choose where in memory primitives and objects are allocated.
• Garbage Collection takes the control of when objects are deleted from memory. Java does not allow programmers to force garbage collection (even with System.gc()) and they cannot delete one particular object. While this makes programming much simpler and prevents memory leaks, in some cases memory can be handled more efficiently in lower-level languages such as C or assembly language.

Language choices

• Java designers decided not to implement certain features present in other languages (incl. multiple inheritance, operator overloading, and class properties).
• Java's primitive types are not objects. Primitive types hold their values in the stack rather than being references to values. This was a conscious decision by Java's designers for performance reasons. Because of this, Java is not considered to be a pure object-oriented programming language.
• Java is predominantly a single-paradigm language. The addition of static imports in Java 5.0 accomodates the procedural paradigm better than earlier versions of Java.

Regular expressions (outdated criticism)

• Java's support of text matching and manipulation has not been as strong as languages such as Perl, Ruby, or PHP. With the introduction of regular expressions in J2SE 1.4 and scripting which will be introduced in Java SE 6 [5] this should no longer be a problem.

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

Look and feel

The look and feel of GUI applications written in Java using the Swing platform is often 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. The Swing toolkit, written completely in Java, avoids this problem by reimplementing widgets using only the most basic drawing mechanisms that are guaranteed available on all platforms. The drawback is that extra effort is required to resemble the operating platform. While this is possible (using the GTK+ and Windows Look-and-Feel), most users do not know how to change the default Metal Look-And-Feel to one that resembles their native platform, and as a result they are stuck with Java applications that look and feel different from their native applications. Of note however, Apple Computer's own optimized version of the Java Runtime, which is included within the Mac OS X distribution, by default implements its "Aqua" look-and-feel, giving Swing applications on the Macintosh a similar appearance to native software.

Pluggable Look and feel

The Look and feel used in Swing widgets is not hardcoded in the widgets themselves, enabling to change it, even at runtime (see Java tutorial here). This allows programmers to redefine their own Look and feel without having to reimplement the widgets.

Previously, creating a custom Look and feel involved a lot coding to define the different Look and feel properties. Beginning with J2SE 5.0, it is possible to define a Look and feel in an XML property file called synth (skinnable Look and feel).

Performance

It is misleading to make any generalization about the performance of Java programs, because runtime performance is affected much more by the quality of the compiler or JVM than by any intrinsic properties of the language itself. Java bytecode can either be interpreted at run time by a virtual machine, or 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.

There are a few language requirements which incur an unavoidable time penalty, although these features are not unique to Java. Among these are array bounds checking, run-time type checking, and virtual function indirection (although each of these can in some situations be avoided by an optimizing compiler). Also the lack of features can affect performance. For example, Java doesn't have arrays of structures or a true multi-dimensional array, but only an array of references to objects or further arrays. Nor does Java allow returning more than one value from a function without using an object. The net result is that Java code makes more heap allocations than well-written code in some other languages.

The use of a garbage collector to automatically delete objects adds overhead compared to manual deallocation and can have a positive or negative impact, or no discernible impact at all, on performance depending upon the garbage collector implementation and the characteristics of the application's use of objects. With the modern generational garbage collectors used in many JVMs, many applications actually experience greater performance because of faster allocation and deallocation algorithms.

Relative performance of JIT compilers as compared to native compilers can be quite close, and is often a subject of debate. The JIT compilation stage may be time consuming, which is inconvenient for applications that are short-lived and/or contain large amounts of code. Once compiled to native code, however, the performance of the program can be comparable to that achieved by a native compiler, even on numerical tasks. Although Java does not support manual inlining of method calls, many JIT compilers perform this optimization at load time and can exploit information from the runtime environment to guide more effective transformations, such as profile-directed inlining. Dynamic recompilation, as provided by Sun's HotSpot JVM, can exceed the performance of the static compilation available in most other languages by exploiting information that is only available at runtime.

Java was designed with an emphasis on security and portability, and does not support direct access to the machine architecture and address space. Java does not support inline assembly language, however, applications can drop down to native code to access these features using Java Native Interface (JNI) libraries.

Language Irregularies

There are numerous cases of discrepancies between what a programmer might expect Java to do and what it actually does or makes available.

• ResultSet.getInt() will return null even though the specified return value is an int and thus will error if assigned to the primitive type int.
• A ResultSet object is automatically closed when the Statement object that generated it is closed, re-executed, or used to retrieve the next result from a sequence of multiple results, however...
• Database connections and statements are not automatically closed when they fall out of scope as would be expected by a scope definition of any object oriented language.
• Even though braces {} are optional on control syntax like if,else and while, they are not optional on try,catch, or finally.
• The JSP get and set parameters insist on the arbitrary style of capitalizing the first letter of the corresponding bean function name: I.e.<jsp:setProperty name="moe" property="myfunc"/> expects a corresponding setMyfunc(), and even though the following work: setMYFUNC(),setMyFunc(); this one case won't work: setmyfunc().
• Iterators can not be reset.