Criticism

Main article: Criticism of Java 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 some other languages.

Unsigned integer types

Java lacks native unsigned integer types. Unsigned data are 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 many numeric processing fields, including cryptography, which can make Java less convenient to use for these tasks. Although it is possible to partially circumvent this problem with conversion code and using larger data types, it makes using Java cumbersome for handling the unsigned data. While a 32-bit signed integer may be used to hold a 16-bit unsigned value with relative ease, a 32-bit unsigned value would require a 64-bit signed integer. Additionally, a 64-bit unsigned value cannot be stored using any integer type in Java because no type larger than 64 bits exists in the Java language. 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.

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.

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 some criticisms of performance. Java has been demonstrated to run at a decent speed compared with native code, and modern JVM implementations are regularly benchmarked and is typically at least two times slower than C and C++ is 33% slower than C.

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

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 Further information: Java security

The Java platform provides a security architecture which is designed to allow the user to run untrusted bytecode in a "sandboxed" manner to protect against malicious or poorly-written software. This "sandboxing" feature is intended to protect the user by restricting access to certain platform features and APIs which could be exploited by malware, such as accessing the local filesystem, running arbitrary commands, or accessing communication networks.

In recent years, researchers have discovered multiple security flaws in some widely-used Java implementations, including Oracle's, which allow untrusted code to bypass the sandboxing mechanism, exposing users to malicious attacks. (These flaws affect only Java applications which execute arbitrary untrusted bytecode, such as web browser plugins that run Java applets downloaded from public websites. Applications where the user trusts, and has full control over, all Java code being executed are unaffected.)

On August 31, 2012, Java 6 and 7 on the platforms Microsoft-Windows, Mac OS X, and Linux were found to have a serious security flaw that allowed a remote exploit to take place by simply loading a malicious web page. Additionally, Java 5 has been found to be flawed as well.

On January 10, 2013, three computer specialists spoke out against Java, telling Reuters that it was not secure and that people should disable Java. Jaime Blasco, Labs Manager with AlienVault Labs stated that "Java is a mess. It’s not secure", and added a cautious note that "You have to disable it." This vulnerability affects Java 7 and it is unclear if it affects Java 6, so it is suggested that consumers disable it. Security alerts from Oracle announce schedules of critical security-related patches to Java.

On January 14, 2013, security experts said that the update still failed to protect PCs from attack. This exploit hole prompted a response from the United States Department of Homeland Security encouraging users to disable or uninstall Java. Apple blacklisted Java completely for any Mac OS X (Mac operating systems) computer to protect its systems.