La crítica de Java es un complejo de un gran número de diferentes grados de sofisticación de las críticas hechas al lenguaje de programación Java , la plataforma de software del mismo nombre , las decisiones de diseño tomadas sobre la base de este lenguaje y plataforma, así como a la organización. del proceso de desarrollo del lenguaje y la plataforma subyacente.
Las críticas a Java, así como a otras HLL generalizadas y populares , son bastante extensas y heterogéneas. Se pueden distinguir los siguientes aspectos principales de esta crítica.
Ideología básica de Java. Se critica la idea misma de crear un sistema basado en un lenguaje de alto nivel compilado en el bytecode de una máquina virtual y crear un intérprete de bytecode para cada plataforma informática. Además, el subsistema de recolección de basura integrado en el sistema Java puede ser objeto de críticas . Lenguaje Java y plataforma subyacente. Se critican casi todas las soluciones tecnológicas de los desarrolladores de Java, incluido el préstamo de la sintaxis de C/C++, la ideología de la jerarquía de paquetes y su conexión con la jerarquía del árbol de archivos fuente del proyecto, la presencia, el conjunto y las características del funcionamiento de basic tipos de datos escalares y aritmética. Implementación. Se critica la implementación de cálculos de punto flotante, se llama la atención sobre las vulnerabilidades en el sistema de seguridad integrado. Se critica la implementación de mecanismos genéricos de programación en Java . El eslogan de Sun Microsystems " Escribir una vez, ejecutar en todas partes " ( ing. escribir una vez, ejecutar en todas partes ) fue transformado por los críticos en "escribir una vez, depurar en todas partes" (" ing. escribir una vez, depurar en todas partes "), en referencia a numerosas diferencias en la plataforma subyacente que deben tenerse en cuenta al escribir cualquier programa Java no trivial.[ aclarar ] Eficiencia. Las críticas sobre la falta de eficiencia de Java se relacionan principalmente con las primeras versiones de implementación del lenguaje y la plataforma, lanzadas a mediados de la década de 1990. Posteriormente, la avalancha de crecimiento del rendimiento del procesador y la memoria RAM hizo que las críticas al rendimiento de Java fueran mucho menos relevantes. Sin embargo, todavía se pueden encontrar afirmaciones de que las "características genéticas" de los sistemas Java conducen a un exceso de memoria y tiempo de procesamiento, mientras que no brindan ventajas equivalentes sobre herramientas de desarrollo más económicas. Desarrollo. Algunos críticos creen que los mecanismos de desarrollo del lenguaje creados por los propietarios de los derechos de autor del idioma dificultan la inclusión de varias innovaciones en él. También puede encontrar opiniones directamente opuestas, según las cuales los cambios de Java de una versión a otra son demasiado activos y los desarrolladores introducen nuevos elementos en el lenguaje, guiados no tanto por consideraciones técnicas como por la moda, lo que conduce a una complicación injustificada del lenguaje.Cuando se agregaron los genéricos en Java 5.0, la plataforma Java tenía una jerarquía de clases grande y muy utilizada, muchas de las cuales estaban obsoletas . Para garantizar la compatibilidad con versiones anteriores y la capacidad de reutilizar las clases existentes, los genéricos se implementaron utilizando el mecanismo de borrado de tipos (en el código de bytes, los tipos genéricos se reemplazan con referencias sin tipo, lo que permite que la máquina virtual ejecute código con genéricos de la misma manera que lo normal), que impuso severas restricciones a su uso. En otros lenguajes, los genéricos son más poderosos porque se implementan usando diferentes mecanismos. [1] [2] Entonces, por ejemplo, en la plataforma .NET, la implementación de los genéricos se implementó directamente en el núcleo de la máquina virtual que ejecuta el código de bytes, lo que hizo posible, a costa de algunas complicaciones, evitar Java- limitaciones específicas y, al mismo tiempo, facilitó mucho la inclusión de genéricos en cualquiera de los lenguajes implementados en esta plataforma.
Debido a que los genéricos se implementaron mediante el borrado tipo real del parámetro de plantilla no está disponible en tiempo de ejecución . Por lo tanto, las siguientes operaciones no son posibles en Java: [3]
public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Error del compilador ... } E item2 = new E (); // Error del compilador E [] iArray = new E [ 10 ] ; // Error del compilador } }Java no implementa tipos de datos enteros sin signo incorporados . [4] Los datos sin firmar a menudo se generan en programas C , y la ausencia de estos tipos de datos en Java impide la comunicación directa entre programas C y programas Java. Los números grandes sin signo también se utilizan en muchas tareas de procesamiento numérico, incluida la criptografía , lo que puede hacer que Java sea menos adecuado que otros lenguajes de programación para automatizar estas tareas . [5] Si bien es posible sortear parcialmente este problema convirtiendo el código y usando otros tipos de datos, esto hace que sea engorroso trabajar con Java cuando se manejan datos sin firmar. Aunque el tipo de datos para enteros con signo de 32 bits se puede utilizar para almacenar el valor de un número sin signo de 16 bits sin pérdida, un número sin signo de 32 bits requeriría un tipo de entero con signo de 64 bits y, por lo tanto, un número sin signo de 64 bits. El valor no se puede convertir correctamente a ningún tipo de datos enteros en Java, ya que no hay tipos de datos en Java para manejar números con una profundidad de bits superior a 64. En cualquier caso, el consumo de memoria se duplica y cualquier lógica que dependa de las reglas de desbordamiento el código adicional generalmente necesita ser reescrito. Como alternativa, los tipos de datos enteros de Java con signo se pueden usar para emular tipos de datos enteros sin firmar del mismo tamaño; sin embargo, esto requiere un conocimiento detallado del trabajo con operaciones bit a bit complejas . [6] y reduce la legibilidad del código.
Aunque las operaciones de punto flotante en Java se basan principalmente en el estándar aritmético binario de punto flotante IEEE 754 , algunas características no son compatibles ni siquiera con el modificador strictfp comoredondeo directo , características proporcionadas según lo requerido por el estándar IEEE 754. Además , los tipos de datos de punto flotante de alta precisión están permitidos por el estándar IEEE 754, implementado en muchos procesadores , no implementado en Java. [7] [8] [9]
En las primeras versiones de Java (antes de que se implementara HotSpot en Java 1.3 en 2000 ), hubo muchas críticas sobre el bajo rendimiento. Se ha demostrado que Java se ejecuta a velocidades comparables con el código nativo optimizado, y las implementaciones modernas de la máquina virtual de Java se desempeñan regularmente entre las mejores plataformas de lenguaje disponibles en las pruebas de rendimiento, generalmente dentro de las 3 posiciones en relación con C / C++ . [diez]
El rendimiento de Java ha mejorado significativamente en las nuevas versiones en comparación con las anteriores. [11] Se encontró que el rendimiento de los compiladores JIT en comparación con los compiladores de uso general en algunas pruebas adaptadas artificialmente es comparable. [11] [12] [13]
El código de bytes de Java puede interpretarse en tiempo de ejecución por una máquina virtual, o puede compilarse en tiempo de carga del programa o en tiempo de ejecución en código de máquina que se ejecuta directamente en la computadora. La interpretación es más lenta que la ejecución de código nativo, y la compilación en el momento de la carga o ejecución del programa reduce el rendimiento a costa del tiempo de compilación. Las implementaciones modernas de alto rendimiento de la máquina virtual Java utilizan la compilación, por lo que (después de que se activa la compilación JIT ) la aplicación muestra un rendimiento cercano al código específico de la plataforma .
En 2010, hubo un aumento significativo en la cantidad de vulnerabilidades para eludir las restricciones de espacio aislado de JVM en los navegadores, lo que hizo que Java fuera más vulnerable que Acrobat y Flash. [catorce]
Los críticos creen que las versiones actualizadas de la JVM no se usan porque muchos usuarios simplemente no saben que tienen una JVM instalada en su computadora y porque muchos usuarios no saben cómo actualizar la JVM. En cuanto a las computadoras corporativas, muchas empresas limitan los derechos de los usuarios para instalar software e instalar actualizaciones con demasiada lentitud. [14] [15]
Las versiones recientes de JVM tienen opciones de accesibilidad de Java en los navegadores.