Críticas a Java

Java introdujo las excepciones verificadas, donde un método debe declarar las excepciones verificadas que lanza en su firma. Esto puede generar código repetitivo innecesariamente extenso . Ningún lenguaje importante ha seguido el ejemplo de Java en la implementación de excepciones verificadas.

Cuando se añadieron los genéricos a Java 5.0, ya existía un amplio marco de clases (muchas de las cuales ya estaban obsoletas ), por lo que los genéricos se implementaron utilizando el borrado de tipos para permitir la compatibilidad de migración y la reutilización de estas clases existentes. Esto limitó las características que se podían proporcionar, en comparación con otros lenguajes. ^{[ 2 ] [ 3 ]}

Debido a que los genéricos se implementan mediante borrado de tipos, el tipo real de un parámetro de plantilla E no está disponible en tiempo de ejecución. Por lo tanto, las siguientes operaciones no son posibles en Java: ^{[ 4 ]}

public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Error de compilación // ... } E item2 = new E (); // Error de compilación E [] iArray = new E [ 10 ] ; // Error de compilación } }

Además, en 2016 se encontró el siguiente ejemplo que revelaba que Java era inestable y, a su vez, hacía que las JVM que generaban ClassCastExceptions o cualquier otro tipo de error en tiempo de ejecución fueran técnicamente no conformes. ^{[ 5 ]} Esto se corrigió en Java 10.

clase Nullless < T , U > { clase Constrain < B extends U > { // algo aquí } final Constrain <? super T > constrain ; final U u ;Sin valores nulos ( T t ) { u = coerce ( t ); constrain = getConstrain (); }< B extiende U > U upcast ( Constrain < B > constrain , B b ) { return b ; }U coerce ( T t ) { return upcast ( constrain , t ); }Constrain <? super T > getConstrain () { return constrain ; }public static void main ( String [] args ) { String zero = new Nullless < Integer , String > ( 0 ). u ; } }

Por diseño, Java anima a los programadores a pensar en una solución en términos de sustantivos (clases) que interactúan entre sí, y a pensar en verbos (métodos) como operaciones que pueden realizarse sobre o por ese sustantivo. ^{[ 6 ]} Steve Yegge argumenta que esto causa una restricción innecesaria a la expresividad del lenguaje porque una clase puede tener múltiples funciones que operan sobre ella, pero una función está ligada a una clase y nunca puede operar sobre múltiples tipos. ^{[ 7 ]}

Muchos otros lenguajes multiparadigma admiten funciones como una construcción de nivel superior. Al combinarse con otras características como la sobrecarga de funciones (un verbo, varios sustantivos) y las funciones genéricas (un verbo, una familia de sustantivos con ciertas propiedades), el programador puede decidir si resolver un problema específico en términos de sustantivos o verbos. Java versión 8 introdujo algunas características de programación funcional.

Java carece de tipos de enteros sin signo nativos . Los datos sin signo se generan a menudo a partir de programas escritos en C , y la falta de estos tipos impide el intercambio directo de datos entre C y Java. Los números grandes sin signo también se utilizan en varios campos del procesamiento numérico, incluida la criptografía, lo que puede hacer que Java sea más inconveniente para estas tareas. ^{[ 8 ]} Aunque es posible sortear este problema utilizando código de conversión y tipos de datos más grandes, hace que usar Java sea engorroso para manejar datos sin signo. Si bien un entero con signo de 32 bits puede usarse para almacenar un valor sin signo de 16 bits sin pérdida, y un entero con signo de 64 bits un entero sin signo de 32 bits, no existe un tipo más grande para almacenar un entero sin signo de 64 bits. En todos los casos, la memoria consumida puede duplicarse, y normalmente cualquier lógica que dependa del desbordamiento del complemento a dos debe reescribirse. Si se abstrae, las llamadas a funciones se vuelven necesarias para muchas operaciones que son nativas de algunos otros lenguajes. Alternativamente, es posible usar enteros con signo de Java para emular enteros sin signo del mismo tamaño, pero esto requiere un conocimiento detallado de las operaciones bit a bit . ^{[ 9 ]} Se proporcionó cierto soporte para tipos de enteros sin signo en JDK 8, pero no para bytes sin signo y sin soporte en el lenguaje Java. ^{[ 10 ]}

Java ha sido criticado por no admitir operadores definidos por el usuario. La sobrecarga de operadores mejora la legibilidad, ^{[ 11 ]} por lo que su ausencia puede hacer que el código Java sea menos legible, especialmente para clases que representan objetos matemáticos, como números complejos y matrices. Java solo tiene un uso no numérico de un operador: para la concatenación de cadenas. Sin embargo, esto lo implementa el compilador, que genera código para crear instancias. Es imposible crear sobrecargas de operadores definidas por el usuario.++=StringBuilder

Java carece de tipos de valor compuestos, como las estructuras en C, conjuntos de datos que se manipulan directamente en lugar de indirectamente a través de referencias. Los tipos de valor a veces pueden ser más rápidos y pequeños que las clases con referencias. ^{[ 12 ] [ 13 ] [ 14 ]} Por ejemplo, el de Java HashMapse implementa como una matriz de referencias a HashMap.Entryobjetos, ^{[ 15 ]} que a su vez contienen referencias a objetos clave y valor. Buscar algo requiere una doble desreferenciación ineficiente. Si Entryfuera un tipo de valor, la matriz podría almacenar pares clave-valor directamente, eliminando la primera indirección, aumentando la localidad de referencia y reduciendo el uso de memoria y la fragmentación del montón . Además, si Java admitiera tipos primitivos genéricos, las claves y los valores podrían almacenarse en la matriz directamente, eliminando ambos niveles de indirección.

Java ha sido criticado por no admitir arreglos de ^2³¹ (aproximadamente 2100 millones) o más elementos. ^{[ 16 ] [ 17 ]} Esta es una limitación del lenguaje; la Especificación del Lenguaje Java , Sección 10.4, establece que:

Los arreglos deben indexarse ​​mediante valores enteros... Intentar acceder a un componente de un arreglo con un índice largo produce un error de compilación. ^{[ 18 ]}

La compatibilidad con grandes matrices también requeriría cambios en la JVM. ^{[ 19 ]} Esta limitación se manifiesta en áreas como las colecciones, que están limitadas a 2 mil millones de elementos ^{[ 20 ]} , y la incapacidad de mapear en memoria segmentos de archivos continuos mayores de 2  GB. ^{[ 21 ]} Java también carece (aparte de sus matrices 2D) de matrices multidimensionales (bloques de memoria únicos asignados contiguamente y a los que se accede mediante una sola indirección), lo que limita el rendimiento para la computación científica y técnica. ^{[ 13 ]}

Los arreglos y los tipos primitivos son algo especiales y deben tratarse de manera diferente a las clases. Esto ha sido criticado ^{[ 22 ]} porque requiere muchas variantes de funciones al crear bibliotecas de propósito general.

Per Brinch Hansen argumentó en 1999 ^{[ 23 ]} que la implementación del paralelismo en Java, en general, y los monitores en particular, no proporcionan las garantías y los mecanismos de control necesarios para una programación paralela segura y confiable. Si bien un programador puede establecer convenciones de diseño y codificación , el compilador no puede hacer ningún intento por aplicarlas, por lo que el programador puede escribir, sin darse cuenta, código inseguro o poco confiable.

Java proporciona un mecanismo para la serialización de objetos , donde un objeto puede representarse como una secuencia de bytes que incluye sus campos de datos, junto con información de tipo sobre sí mismo y sus campos. Después de serializar un objeto, este puede deserializarse; es decir, la información de tipo y los bytes que representan sus datos pueden usarse para recrear el objeto en memoria. ^{[ 24 ]} Esto plantea riesgos de seguridad teóricos y reales muy serios. ^{[ 25 ] [ 26 ]}

Aunque la aritmética de punto flotante de Java se basa en gran medida en IEEE 754 ( Estándar para la aritmética binaria de punto flotante ), algunas características estándar obligatorias no son compatibles incluso cuando se utiliza el modificador (ahora redundante ^{[ 27 ]} ) strictfp, como los indicadores de excepción y el redondeo dirigido. Los tipos de precisión extendida definidos por IEEE 754 (y compatibles con muchos procesadores) no son compatibles con Java. ^{[ 28 ] [ 29 ] [ 30 ]}

Java no admite tuplas de forma nativa , lo que da lugar a una proliferación de implementaciones de terceros que deben ser importadas y gestionadas por el programador. ^{[ 31 ]} El argumento en contra de una clase de tupla genérica es el peligro que supone al proliferar código difícil de mantener. ^{[ 32 ]}

Antes de Java 7, los instaladores no eliminaban las instalaciones antiguas de Java. Era común encontrar varias instalaciones de Java en un mismo equipo Windows. ^{[ 49 ] [ 50 ] [ 51 ]} Se permitían las instalaciones múltiples, las cuales podían ser utilizadas por programas que dependían de versiones específicas, incluyendo programas maliciosos. Este problema se solucionó en Java 7: con el permiso del usuario, el instalador elimina las instalaciones anteriores. ^{[ 52 ]}

La compilación JIT utiliza fundamentalmente datos ejecutables y, por lo tanto, plantea desafíos de seguridad y posibles vulnerabilidades.