El lenguaje de programación Java y la plataforma de software Java han sido criticados por las opciones de diseño en el lenguaje y la plataforma, incluida la implementación de genéricos, la programación forzada orientada a objetos, el manejo de números sin signo, la implementación de aritmética de punto flotante y una historia de vulnerabilidades de seguridad en la implementación principal de Java VM, HotSpot . Además, el software escrito en Java, especialmente sus primeras versiones, ha sido criticado por su rendimiento en comparación con el software escrito en otros lenguajes de programación. Los desarrolladores también han señalado que las diferencias en varias implementaciones de Java deben tenerse en cuenta al escribir programas complejos de Java que deben usarse en todas estas implementaciones. [1]
Sintaxis y semántica del lenguaje
Genéricos
Cuando se agregaron los genéricos a Java 5.0, ya existía un gran marco de clases (muchas de las cuales ya estaban en desuso ), por lo que se eligieron los genéricos para implementarlos mediante el borrado de tipos para permitir la compatibilidad de la migración y la reutilización de estas clases existentes. Esto limitó las funciones que podría proporcionar esta adición en comparación con otros idiomas. [2] [3]
Debido a que los genéricos se implementaron mediante el borrado de tipos, el tipo real de un parámetro de plantilla común E no está disponible en tiempo de ejecución. Por tanto, las siguientes operaciones no son posibles en Java: [4]
public class MyClass < E > { public static void myMethod ( elemento de objeto ) { if ( instancia de elemento de E ) { // Error del compilador ... } E item2 = new E (); // Error del compilador E [] iArray = new E [ 10 ] ; // Error del compilador } }
Orientación sustantiva
Por diseño, Java anima a los programadores a pensar en una solución de programación en términos de sustantivos (clases) que interactúan entre sí, y a pensar en los verbos (métodos) como operaciones que se pueden realizar en o por ese sustantivo. [5] Steve Yegge sostiene que esto provoca una restricción innecesaria en la expresividad del lenguaje porque una clase puede tener múltiples funciones que operan en ella, pero una función está ligada a una clase y nunca puede operar en múltiples tipos. [6]
En muchos otros lenguajes de múltiples paradigmas , hay soporte para funciones como una construcción de nivel superior. Cuando se combina con otras características del lenguaje, como la sobrecarga de funciones (un verbo, varios sustantivos) y / o funciones genéricas (un verbo, una familia de sustantivos con ciertas propiedades), el programador tiene la capacidad de decidir si tiene más sentido resolver un problema específico en términos de sustantivos o verbos. La versión 8 de Java introdujo algunas características de programación funcional.
Relación oculta entre código y hardware
En 2008, el Centro de Soporte Tecnológico de Software del Departamento de Defensa de EE. UU . Publicó en el "Journal of Defense Software Engineering" un artículo en el que se discutía la inadecuación de Java como primer lenguaje de programación aprendido en educación. Las desventajas dadas para Java como primer idioma fueron que los estudiantes "no tenían idea de la relación entre el programa fuente y lo que haría realmente el hardware" y la imposibilidad "de desarrollar una idea del costo en tiempo de ejecución de lo que está escrito porque es extremadamente difícil saber lo que eventualmente ejecutará cualquier llamada de método ". [7] De manera similar, Joel Spolsky en 2005, criticó a Java como parte excesivamente enfocada del plan de estudios de las universidades en su ensayo The Perils of JavaSchools . [8] Otros, como Ned Batchelder, no están de acuerdo con Spolsky por criticar las partes del lenguaje que le resultaban difíciles de entender, alegando que el comentario de Spolsky era más una "perorata subjetiva". [9]
Tipos de enteros sin signo
Java carece de tipos enteros nativos sin signo . Los datos sin firmar a menudo se generan a partir de programas escritos en C , y la falta de estos tipos evita el intercambio directo de datos entre C y Java. Los números grandes sin firmar también se utilizan en varios campos de procesamiento numérico, incluida la criptografía, lo que puede hacer que Java sea más incómodo para estas tareas. [10] Aunque es posible eludir parcialmente este problema con el código de conversión y el uso de tipos de datos más grandes, hace que el uso de Java sea engorroso para manejar datos sin firmar. Mientras que un entero de 32 bits con signo puede usarse para contener un valor sin signo de 16 bits sin pérdida y un valor sin signo de 32 bits requeriría un entero de 64 bits con signo, un valor sin signo de 64 bits no se puede almacenar fácilmente usando ningún tipo de entero porque no existe ningún tipo mayor de 64 bits en el lenguaje Java. En todos los casos, la memoria consumida puede aumentar en un factor de hasta dos, y cualquier lógica que dependa de las reglas del desbordamiento del complemento a dos normalmente debe reescribirse. Si se abstraen usando funciones, 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 . [11] Se proporcionó algo de soporte para tipos de enteros sin firmar en JDK 8, pero no para bytes sin firmar y sin soporte en el lenguaje Java. [12]
Sobrecarga del operador
Java ha sido criticado por no admitir la capacidad de implementar operadores definidos por el usuario. [ cita requerida ] La sobrecarga del operador mejora la legibilidad, [13] por lo tanto, la falta de ella en Java puede hacer que el código sea menos legible, especialmente para las clases que representan objetos matemáticos, como números complejos, matrices, etc. El lenguaje contiene solo un código no numérico uso para los operadores, y eso es la concatenación de cadenas, implementada con el +
operador. Sin embargo, esto se implementa solo en el compilador y se compila en un StringBuilder; es imposible crear sobrecargas de operadores definidos por el usuario.
Tipos de valor compuesto
Java carece de tipos de valores compuestos, como estructuras en C, paquetes de datos que se manipulan directamente en lugar de indirectamente a través de referencias. Los tipos de valor pueden ofrecer importantes mejoras de rendimiento y ahorros de memoria en algunos casos. [14] [15] [16] Un ejemplo típico es el de Java HashMap
, que se implementa internamente como una matriz de HashMap.Entry
objetos. [17] Debido a que Java carece de tipos de valor, esta matriz es en realidad una matriz de referencias (punteros) a Entry
objetos, que a su vez contiene referencias a objetos clave y de valor. Buscar algo en el mapa requiere una doble indirecta ineficiente. Si Entry
fuera un tipo de valor, la matriz podría almacenar pares de referencias de clave y valor directamente, eliminando la primera indirección, aumentando la localidad y reduciendo el uso de memoria y la fragmentación del montón . Si Java soportaba aún más los tipos primitivos genéricos, las claves y valores primitivos podrían almacenarse directamente en la matriz, eliminando la segunda indirección.
Grandes matrices
Se ha criticado a Java por no admitir matrices de más de 2 31 −1 (aproximadamente 2.100 millones) de elementos. [18] [19] [20] Esta es una limitación del idioma; la Especificación del lenguaje Java , Sección 10.4, establece que:
Las matrices deben estar indexadas por valores int ... Un intento de acceder a un componente de matriz con un valor de índice largo da como resultado un error en tiempo de compilación. [21]
El soporte de matrices grandes también requeriría cambios en la JVM. [22] Esta limitación se manifiesta en áreas tales como que las colecciones estén limitadas a 2 mil millones de elementos [23] y la incapacidad para mapear en memoria segmentos de archivos continuos mayores de 2 GB. [24] Java también carece de verdaderas matrices multidimensionales (bloques únicos de memoria asignados de forma contigua a los que se accede mediante una única dirección indirecta), lo que limita el rendimiento de la informática científica y técnica. [15]
No existe una forma eficaz de inicializar matrices en Java. Al declarar una matriz, la JVM la compila en códigos de bytes con instrucciones que establecen sus elementos uno por uno en tiempo de ejecución. Debido a que los métodos Java no pueden superar los 64 KB, las matrices de tamaños incluso modestos con valores asignados directamente en el código mostrarán el mensaje "Error: código demasiado grande" en la compilación. [25] [se necesita una mejor fuente ]
Integración de primitivas y matrices
Se ha criticado el hecho de que las matrices y primitivas sean algo especiales y deban tratarse de manera diferente a (otros) objetos, [26] porque requiere escribir muchas variantes al crear bibliotecas generales.
Paralelismo
Per Brinch Hansen argumentó en 1999 [27] que la implementación de Java del paralelismo en general y los monitores en particular no proporcionan las garantías y el cumplimiento necesarios para una programación paralela segura y confiable. Si bien es posible que un programador establezca convenciones de diseño y codificación para, digamos, acceder solo a variables globales de subprocesos de forma controlada, el lenguaje y el compilador no intentan imponer ese acceso controlado. Es decir, el programador puede permitir por error el acceso incontrolado a las variables globales del hilo y el compilador no lo detectará.
Publicación por entregas
Java proporciona un mecanismo llamado serialización de objetos, donde un objeto se puede representar como una secuencia de bytes que incluye los datos del objeto, así como información sobre el tipo de objeto y los tipos de datos almacenados en el objeto. Una vez que un objeto serializado se ha escrito en un archivo, se puede leer desde el archivo y deserializar; es decir, la información de tipo y los bytes que representan el objeto y sus datos se pueden usar para recrear el objeto en la memoria. [28] Esto plantea riesgos de seguridad reales y teóricos muy graves. [29] [30]
Aritmética de coma flotante
Aunque la aritmética de coma flotante de Java se basa en gran medida en IEEE 754 ( estándar para aritmética de coma flotante binaria ), ciertas funciones no son compatibles incluso cuando se usa el strictfp
modificador, como las banderas de excepción y el redondeo dirigido, capacidades exigidas por la norma 754 de IEEE. Los tipos de punto flotante de precisión extendida permitidos en 754 y presentes en muchos procesadores no están permitidos en Java. [31] [32] [33]
Actuación
En los primeros días de Java (antes de que HotSpot VM se implementara en Java 1.3 en 2000) hubo muchas críticas sobre el rendimiento. Se ha demostrado que Java se ejecuta a una velocidad comparable con el código nativo optimizado, y las implementaciones modernas de JVM se evalúan regularmente como una de las plataformas de lenguaje más rápidas disponibles, generalmente con un factor de 3 en relación con C y C ++. [34]
El rendimiento de Java ha mejorado sustancialmente desde las primeras versiones. [35] En algunas pruebas optimizadas, se ha demostrado que el rendimiento de los compiladores JIT en relación con los compiladores nativos es bastante similar. [35] [36] [37]
El código de bytes de Java puede ser interpretado en tiempo de ejecución por una máquina virtual, o puede ser compilado en tiempo de carga o en tiempo de ejecución en código nativo que se ejecuta directamente en el hardware de la computadora. La interpretación es más lenta que la ejecución nativa y la compilación en tiempo de carga o en tiempo de ejecución tiene una penalización de rendimiento inicial para la compilación. Todas las implementaciones modernas de JVM de rendimiento utilizan el enfoque de compilación, por lo que después del tiempo de inicio inicial, el rendimiento es similar al del código nativo.
El diseñador y programador de juegos John D. Carmack concluyó en 2005 sobre Java en teléfonos móviles : "El mayor problema es que Java es realmente lento. En un nivel puro de cpu / memoria / pantalla / comunicaciones, la mayoría de los teléfonos móviles modernos deberían ser considerablemente mejores para juegos plataformas que una Game Boy Advance. Con Java, en la mayoría de los teléfonos te quedas con la potencia de CPU de una PC IBM original de 4,77 mhz (sic) y un pésimo control sobre todo ". [38]
Seguridad
La plataforma Java proporciona una arquitectura de seguridad [39] que está diseñada para permitir que el usuario ejecute un código de bytes que no sea de confianza en una forma de "caja de arena" para protegerse contra software malicioso o mal escrito. Esta función de "espacio aislado" está destinada a proteger al usuario restringiendo el acceso a determinadas funciones de la plataforma y API que podrían ser explotadas por malware , como acceder al sistema de archivos local, ejecutar comandos arbitrarios o acceder a redes de comunicación.
En 2010, hubo un aumento significativo en la prevalencia de software malicioso dirigido a fallas de seguridad en el mecanismo de espacio aislado en múltiples implementaciones de Java de uso común, incluida la de Oracle. Estas fallas permiten que el código que no es de confianza eluda las restricciones de la zona de pruebas, exponiendo al usuario a ataques maliciosos. Las fallas de seguridad específicas que ya han sido corregidas por las actualizaciones de seguridad de los mantenedores de JVM se han aprovechado en computadoras sin las actualizaciones de seguridad. [40]
Los críticos han sugerido que no se utilizan versiones actualizadas de Java porque muchos usuarios no saben que Java está instalado, hay una falta general de conocimiento sobre cómo actualizar Java y (en computadoras corporativas) muchas empresas restringen la instalación de software. y son lentos para implementar actualizaciones. [40] [41]
Oracle ha sido criticado por no proporcionar actualizaciones de seguridad de Java para errores de seguridad conocidos, durante largos períodos de tiempo, a pesar de que estos errores de seguridad tienen exploits conocidos. [42] Cuando Oracle finalmente actuó para parchear fallas ampliamente explotadas en Java 7, eliminaron Java 6 en las máquinas de los usuarios a pesar de que esto era ampliamente utilizado por aplicaciones empresariales que Oracle había afirmado que no se vieron afectadas por las fallas. [43]
En 2007, un equipo de investigación dirigido por Marco Pistoia , expuso otra falla importante del modelo de seguridad de Java, [44] que se basa en la inspección de pila . Esto significa que, en el momento en que se está a punto de acceder a un recurso sensible a la seguridad, el administrador de seguridad activa un recorrido de la pila, que verifica que el código base de cada método en la pila de llamadas actual haya sido autorizado para acceder al recurso sensible a la seguridad. Esto se hace para evitar ataques confusos de agentes , que tienen lugar cada vez que otro programa engaña a un programa informático legítimo y más privilegiado para que haga un mal uso de su autoridad en el sistema. El problema del diputado confuso es un tipo específico de escalada de privilegios . El problema con este enfoque según lo observado por Marco Pistoia , et al. es que en el momento en que se accede a un recurso sensible a la seguridad, es posible que el código responsable de la identificación de ese recurso ya no esté en la pila actual. Por ejemplo, un método ejecutado en el pasado puede haber modificado el valor de un campo de objeto, que se utiliza para determinar el recurso al que se accede. Es posible que ese método ya haya salido de la pila cuando se lleva a cabo la inspección de la pila. Otras limitaciones del modelo de seguridad de Java es que ciertos permisos son implícitamente equivalentes a los de Java AllPermission
. Estos incluyen el permiso para cambiar el administrador de seguridad actual (y reemplazarlo con uno que podría pasar por alto la inspección de la pila), el permiso para crear una instancia y usar un cargador de clases personalizado (que podría optar por asociarse AllPermission
a una clase maliciosa al cargarlo), y el permiso para crear un permiso personalizado (que potencialmente podría declararse tan poderoso como a AllPermission
través de una implementación maliciosa de su implies
método). Estos problemas también están documentados en los dos libros de Marco Pistoia sobre seguridad Java : Java 2 Network Security (segunda edición) y Enterprise Java Security .
Varias instalaciones Java paralelas
Con las versiones de Java anteriores a la 7, era normal que el instalador no detectara ni eliminara las instalaciones de Java anteriores. Era bastante común en una computadora con Windows ver múltiples instalaciones de Java 6 en la misma computadora, variando solo según la revisión de la actualización. Se permiten múltiples Java y se puede acceder a ellos mediante programas que buscan versiones específicas.
Esto tiene el efecto de que las nuevas instalaciones de Java solo proporcionan nuevas funciones de lenguaje y correcciones de errores, pero no corrigen las vulnerabilidades de seguridad, porque los programas maliciosos pueden buscar las versiones anteriores de Java y utilizarlas en lugar de las versiones más nuevas.
Java 7 actualizó versiones anteriores de sí mismo, pero no buscó la presencia de Java 6 y anteriores. [45]
Sin capacidad de actualización automática
A partir de 2014, las herramientas comunes de terceros (como Adobe Flash y Adobe Reader) que han sido objeto de un escrutinio de vulnerabilidades de seguridad, se han trasladado a un modelo de actualización automática en Windows. Este modelo no requiere la intervención del usuario y asegura que los problemas de seguridad se resuelvan rápidamente sin requerir un esfuerzo adicional por parte de los usuarios o administradores del sistema.
A partir de 2015, Java 8 todavía requiere que el usuario de la computadora aplique manualmente las actualizaciones de Java. Estas actualizaciones solo pueden ser aplicadas por aquellos con privilegios de administrador. El actualizador de Java de Windows activa con frecuencia un aviso de elevación aleatorio del Control de cuentas de usuario; sin embargo, si elige Sí o No para la elevación, seguirá apareciendo el mismo mensaje "Java debe actualizarse".
Ver también
- Comparación de Java y C ++
- Comparación de Java y C #
- Comparación de las plataformas Java y .NET
- Rendimiento de Java
- Escribe una vez, corre a cualquier lugar
Notas
- ^ Wong, William (27 de mayo de 2002). "Escriba una vez, depure en todas partes" . electronicdesign.com. Archivado desde el original el 21 de marzo de 2009 . Consultado el 3 de agosto de 2008 .
Hasta ahora, la promesa de "escribir una vez, ejecutar en todas partes" de Java no se ha hecho realidad. La mayor parte de una aplicación Java migrará entre la mayoría de las implementaciones de Java, pero aprovechar una característica específica de la máquina virtual causa problemas de migración.
- ^ "Genéricos en Java" . Object Computing, Inc. Archivado desde el original el 2 de enero de 2007 . Consultado el 9 de diciembre de 2006 .
- ^ "¿Qué está mal con Java: borrado de tipos" . 6 de diciembre de 2006 . Consultado el 9 de diciembre de 2006 .
- ^ "Borrado de tipo" .
- ^ "Especificaciones de Java SE" .
- ^ Yegge, Steve. "Ejecución en el Reino de los Sustantivos" .
- ^ Robert BK Dewar; Edmond Schonberg (1 de enero de 2008). "Educación en Ciencias de la Computación: ¿Dónde están los ingenieros de software del mañana?" . CrossTalk enero de 2008 . Centro de soporte tecnológico de software del Departamento de Defensa de EE. UU . Archivado desde el original el 12 de abril de 2009 . Consultado el 15 de marzo de 2015 .
Las trampas de Java como primer lenguaje de programación [...] Los estudiantes encontraron difícil escribir programas que no tuvieran una interfaz gráfica, no sintieran la relación entre el programa fuente y lo que el hardware realmente haría, y (la mayoría dañino) no entendía la semántica de los punteros en absoluto, lo que hacía que el uso de C en la programación de sistemas fuera muy desafiante.
- ^ Joel Spolsky (29 de diciembre de 2005). "Joel en software - Los peligros de JavaSchools" . joelonsoftware . Consultado el 18 de noviembre de 2015 .
Ya es bastante malo que JavaSchools no elimine a los niños que nunca serán grandes programadores, lo que las escuelas podrían decir con razón que no es su problema. La industria, o, al menos, los reclutadores-que-usan-grep, seguramente están pidiendo a gritos que se enseñe Java. Pero JavaSchools tampoco capacita a los cerebros de los niños para que sean expertos, ágiles y lo suficientemente flexibles como para hacer un buen diseño de software.
- ^ Ned Batchelder (1 de enero de 2006). "Joel Spolsky es un viejo cascarrabias" . nedbatchelder.com . Consultado el 2 de febrero de 2016 .
¿Por qué Joel elige punteros y recursividad como los dos conceptos de guardián? ¿Porque los encontró difíciles? Como señala Tim Bray, Java es perfectamente experto en la recursividad, y la concurrencia puede ser un concepto más importante y difícil de dominar en cualquier caso. El énfasis en la recursividad en los lenguajes Lisp es un poco exagerado y no se traslada a otras culturas de programación. ¿Por qué la gente piensa que es tan importante para la ingeniería de software? No me malinterpretes: me encanta la recursividad cuando es la herramienta adecuada para el trabajo, pero eso no suele justificar que Joel se centre en ella como un concepto fundamental.
Mientras buscamos conceptos difíciles que separen a los hombres de los niños, ¿qué pasa con el que nos metió a Joel y a mí en una pelea hace dos años? Excepciones. No le gustan, básicamente, porque lo confunden. ¿Es esto diferente a un tipo de Java al que no le gustan los punteros? Sí, puede evitar excepciones y utilizar devoluciones de estado, pero también puede esforzarse mucho para evitar los indicadores. ¿Eso significa que deberías? Así que Joel tiene los conceptos que le gustan (punteros y recursividad), y lamenta su declive, pero no parece darse cuenta de que hay conceptos más nuevos que nunca ha captado, con los que los niños de Java se sienten como en casa. - ^ "Las bibliotecas de Java deberían proporcionar soporte para aritmética de enteros sin firmar" . Base de datos de errores, Sun Developer Network . Oracle . Consultado el 18 de enero de 2011 .
- ^ Owen, Sean R. (5 de noviembre de 2009). "Java y unsigned int, unsigned short, unsigned byte, unsigned long, etc. (O más bien, la falta de ellos)" . Consultado el 9 de octubre de 2010 .
- ^ "API aritmética de enteros sin firmar ahora en JDK 8 (Weblog de Oracle de Joseph D. Darcy)" . Consultado el 15 de mayo de 2016 .
- ^ "Sobrecarga del operador C ++" . 7 de abril de 2016.
- ^ Panel del Foro de Java Grande (noviembre de 1998). "Informe del Foro de Java Grande: hacer que Java funcione para la informática de alta gama" (PDF) . SC98 .
- ^ a b Moreira, JE; SP Midkiff; M. Gupta; PV Artigas; M. Snir; RD Lawrence (2000). "Programación Java para computación numérica de alto rendimiento". Revista de sistemas de IBM . 39 (1): 21–56. CiteSeerX 10.1.1.13.1554 . doi : 10.1147 / sj.391.0021 .
Las matrices multidimensionales rectangulares verdaderas son las estructuras de datos más importantes para la informática científica y de ingeniería.
- ^ Hutchinson, Ben (14 de junio de 2008). "La JVM necesita tipos de valor" . Consultado el 3 de febrero de 2012 .
- ^ "Código fuente java.util.HashMap" . JDK 8 . zGrepCode . Consultado el 6 de agosto de 2018 .
- ^ Arndt, Holger; Bundschus, Markus; Naegele, Andreas (2009). "Hacia una biblioteca de matrices de próxima generación para Java" (PDF) . 2009 33ª Conferencia Anual de Aplicaciones y Software Informático Internacional IEEE . págs. 460–467. CiteSeerX 10.1.1.471.7567 . doi : 10.1109 / compsac.2009.67 . ISBN 978-0-7695-3726-9.
... no es posible en Java tener matrices con más de 2 31 entradas ...
- ^ "¿Por qué Collection.size () de Java devuelve un int?" . Desbordamiento de pila . Archivado desde el original el 26 de marzo de 2013 . Consultado el 10 de febrero de 2012 .
- ^ Carpenter, Bob (28 de julio de 2010). "Abstracción de matriz de gran paquete de bits (para Java, C, etc.)" . Blog de LingPipe . Consultado el 10 de febrero de 2012 .
- ^ James Gosling; Bill Joy; Guy Steele; Gilad Bracha. "La especificación del lenguaje Java" (Tercera ed.). Addison Wesley . Consultado el 6 de febrero de 2012 .
- ^ Lowden, James. "Propuesta: Matrices grandes (toma dos)" . Lista de correo Java.net coin-dev . Consultado el 10 de febrero de 2012 .
- ^ "java.util.Collection" . Plataforma Java ™, Especificación API Standard Edition 7 . Consultado el 10 de febrero de 2012 .
- ^ "java.nio.ByteBuffer" . Plataforma Java ™, Especificación API Standard Edition 7 . Consultado el 6 de febrero de 2012 .
- ^ David Flanagan. Java en pocas palabras . pag. 77.
- ^ Sherman R. Alpert (IBM) (1998). "Tipos primitivos considerados nocivos" . Java Report, noviembre de 1998 (Volumen 3, Número 11) . Consultado el 18 de noviembre de 2015 .
- ^ Brinch Hansen (abril de 1999). "Paralelismo inseguro de Java" (PDF) . SIGPLAN . Consultado el 13 de octubre de 2012 .; URL alternativa
- ^ Serialización y deserialización en Java con ejemplo por el sitio web geeksforgeeks
- ^ La serialización debe morir Problemas de seguridad y problemas con la serialización de objetos aleatorios. por dzone.com
- ^ Bloch, Joshua (2018). Java eficaz . Addison-Wesley. págs. 339–345. ISBN 978-0-13-468599-1.
- ^ Kahan, W .; Joseph D. Darcy (1 de marzo de 1998). "Cómo el punto flotante de Java perjudica a todos en todas partes" (PDF) . Consultado el 9 de diciembre de 2006 .
- ^ "Tipos, valores y variables" . Sun Microsystems . Consultado el 9 de diciembre de 2006 .
- ^ "Teoría y práctica de Java: ¿Dónde está tu punto? Trucos y trampas con coma flotante y números decimales" . IBM. 1 de enero de 2003 . Consultado el 19 de noviembre de 2011 .
- ^ "Juego de pruebas de lenguaje de computadora: Java vs Gnu C ++" . benchmarksgame.alioth.debian.org. Archivado desde el original el 13 de enero de 2015 . Consultado el 19 de noviembre de 2011 .
- ^ a b JPLewis y Ulrich Neumann. "Rendimiento de Java versus C ++" . Laboratorio de Gráficos y Tecnología Inmersiva, Universidad del Sur de California .
- ^ "El Java más rápido que C ++ Benchmark" . Consultado el 15 de mayo de 2016 .
- ^ FreeTTS: un estudio de caso de rendimiento Archivado el 25 de marzo de 2009 en Wayback Machine , Willie Walker, Paul Lamere, Philip Kwok
- ^ John D. Carmack (27 de marzo de 2005). "Aventuras con el teléfono celular" . Blog de John Carmack . armadilloaerospace.com. Archivado desde el original el 24 de noviembre de 2015 . Consultado el 10 de noviembre de 2015 .
- ^ Arquitectura de seguridad de la plataforma Java SE . Oráculo. Consultado el 23 de abril de 2013.
- ^ a b "Los investigadores destacan el reciente repunte de las vulnerabilidades de seguridad de Java" .
- ^ "¿Ha revisado Java?" . Archivado desde el original el 3 de septiembre de 2012 . Consultado el 25 de noviembre de 2010 .
- ^ "Oracle conocía las fallas críticas de Java desde abril" . 30 de agosto de 2012 . Consultado el 30 de agosto de 2012 .
- ^ " La actualización de seguridad de Java ' silenciosa pero mortal' rompe las aplicaciones heredadas - dev" . Consultado el 15 de mayo de 2016 .
- ^ Pistoia, Marco; Banerjee, Anindya; Naumann, David A. (mayo de 2007). "Más allá de la inspección de la pila: un modelo de seguridad de flujo de información y control de acceso unificado". 2007 Simposio IEEE sobre seguridad y privacidad (SP '07) . IEEE: 149-163. doi : 10.1109 / sp.2007.10 . ISBN 978-0-7695-2848-9.
- ^ "Adjunto A" . www.java.com . Consultado el 3 de marzo de 2018 .
enlaces externos
- Free But Shackled - The Java Trap , un ensayo de Richard Stallman sobre el movimiento del software libre (fechado el 12 de abril de 2004)
- Educación en ciencias de la computación: ¿Dónde están los ingenieros de software del mañana? (de fecha 8 de enero de 2008)
- ¿Cuáles son las malas características de Java?