Máquina virtual de Java

"JRE" vuelve a dirigir aquí. Para ver el podcast de Joe Rogan , consulte The Joe Rogan Experience . Para la compañía de ferrocarriles japonesa, consulte JR East .

Máquina virtual

Máquina virtual de Java

Diseñador	Microsistemas solares
Bits	32 bits
Introducido	1994
Versión	15.0.2 [1]
Escribe	Apilar y registrar - registrar
Codificación	Variable
Derivación	Comparar y bifurcar
Endianidad	Grande
Abierto	sí
Registros
Propósito general	Pila de operandos por método (hasta 65535 operandos) más variables locales por método (hasta 65535)

Descripción general de la arquitectura de una máquina virtual Java (JVM) basada en la especificación de la máquina virtual Java Java SE 7 Edition

Una máquina virtual Java ( JVM ) es una máquina virtual que permite a una computadora ejecutar programas Java , así como programas escritos en otros lenguajes que también se compilan en código de bytes Java . La JVM se detalla mediante una especificación que describe formalmente lo que se requiere en una implementación de JVM. Tener una especificación garantiza la interoperabilidad de los programas Java en diferentes implementaciones, de modo que los autores de programas que utilizan Java Development Kit (JDK) no necesitan preocuparse por las idiosincrasias de la plataforma de hardware subyacente.

La implementación de referencia JVM es desarrollada por el proyecto OpenJDK como código fuente abierto e incluye un compilador JIT llamado HotSpot . Las versiones de Java con soporte comercial disponibles de Oracle Corporation se basan en el tiempo de ejecución de OpenJDK. Eclipse OpenJ9 es otra JVM de código abierto para OpenJDK.

Especificación de JVM

La máquina virtual Java es una computadora abstracta (virtual) definida por una especificación. El algoritmo de recolección de basura utilizado y cualquier optimización interna de las instrucciones de la máquina virtual Java (su traducción al código de la máquina) no se especifican. La razón principal de esta omisión es no restringir innecesariamente a los implementadores. Cualquier aplicación Java se puede ejecutar solo dentro de alguna implementación concreta de la especificación abstracta de la máquina virtual Java. ^[2]

A partir de Java Platform, Standard Edition (J2SE) 5.0, los cambios a la especificación JVM se han desarrollado bajo el Proceso de la comunidad Java como JSR 924. ^[3] A partir de 2006 ^[actualizar], los cambios en la especificación para admitir los cambios propuestos al formato de archivo de clase (JSR 202) ^[4] se están realizando como una versión de mantenimiento de JSR 924. La especificación para la JVM se publicó como el libro azul , ^[5] El prefacio dice:

Tenemos la intención de que esta especificación documente suficientemente la máquina virtual Java para hacer posibles implementaciones de sala limpia compatibles. Oracle proporciona pruebas que verifican el correcto funcionamiento de las implementaciones de la Máquina Virtual Java.

Una de las JVM de Oracle se llama HotSpot , la otra heredada de BEA Systems es JRockit . Las implementaciones de Java de sala limpia incluyen Kaffe , OpenJ9 y CEE-J de Skelmir . Oracle es propietario de la marca registrada Java y puede permitir su uso para certificar suites de implementación como totalmente compatibles con la especificación de Oracle.

Cargador de clases

Artículo principal: cargador de clases Java

Una de las unidades organizativas del código de bytes de JVM es una clase. Una implementación de cargador de clases debe poder reconocer y cargar cualquier cosa que se ajuste al formato de archivo de clases de Java. Cualquier implementación es libre de reconocer otras formas binarias además de los archivos de clase , pero debe reconocer los archivos de clase .

El cargador de clases realiza tres actividades básicas en este estricto orden:

1. Cargando: busca e importa los datos binarios de un tipo
2. Vinculación: realiza verificación, preparación y (opcionalmente) resolución
   • Verificación: asegura la exactitud del tipo importado
   • Preparación: asigna memoria para las variables de clase e inicializa la memoria a los valores predeterminados
   • Resolución: transforma las referencias simbólicas del tipo en referencias directas.
3. Inicialización: invoca código Java que inicializa las variables de clase a sus valores iniciales adecuados.

En general, hay dos tipos de cargador de clases: cargador de clases de arranque y cargador de clases definido por el usuario.

Cada implementación de máquina virtual Java debe tener un cargador de clases de arranque, capaz de cargar clases confiables y un cargador de clases de extensión o un cargador de clases de aplicaciones. La especificación de la máquina virtual Java no especifica cómo un cargador de clases debe ubicar las clases.

Arquitectura de la máquina virtual

La JVM opera con valores primitivos (enteros y números de coma flotante) y referencias . La JVM es fundamentalmente una máquina de 32 bits. longy los doubletipos, que son de 64 bits, se admiten de forma nativa, pero consumen dos unidades de almacenamiento en las variables locales de una trama o en la pila de operandos, ya que cada unidad es de 32 bits. boolean, byte, short, Y chartipos son todos de signo extendido (excepto charque es cero extendido ) y operado en como enteros de 32 bits, al igual que inttipos. Los tipos más pequeños solo tienen unas pocas instrucciones específicas de tipo para cargar, almacenar y convertir tipos. booleanse opera como bytevalores de 8 bits , con 0 representando falsey 1 representandotrue. (A pesar de que booleanha sido tratado como un tipo desde el Java Virtual Especificación de la Máquina, segunda edición aclaró este tema, en el compilado y el código que hay poca diferencia entre un ejecutado booleany una byteexcepción de nombre mangling en firmas de método y el tipo de matrices booleanas. booleanS en las firmas de los métodos se alteran Zmientras que los bytes se alteran como B. Las matrices booleanas llevan el tipo boolean[]pero usan 8 bits por elemento, y la JVM no tiene capacidad incorporada para empaquetar booleanos en una matriz de bits , por lo que, excepto por el tipo que realizan y se comportan, lo mismo que las bytematrices. En todos los demás usos, elbooleantype es efectivamente desconocido para la JVM ya que todas las instrucciones para operar en booleanos también se usan para operar en bytes.)

La JVM tiene un montón de recolección de basura para almacenar objetos y matrices. El código, las constantes y otros datos de clase se almacenan en el "área de método". El área del método es lógicamente parte del montón, pero las implementaciones pueden tratar el área del método por separado del montón y, por ejemplo, no pueden recolectarlo como basura. Cada subproceso de JVM también tiene su propia pila de llamadas (llamada "pila de máquina virtual Java" para mayor claridad), que almacena marcos . Se crea un nuevo marco cada vez que se llama a un método, y el marco se destruye cuando ese método sale.

Cada marco proporciona una "pila de operandos" y una matriz de "variables locales". La pila de operandos se usa para operandos para cálculos y para recibir el valor de retorno de un método llamado, mientras que las variables locales tienen el mismo propósito que los registros y también se usan para pasar argumentos de métodos. Por lo tanto, la JVM es tanto una máquina de pila como una máquina de registro .

Instrucciones de bytecode

Artículo principal: código de bytes de Java

La JVM tiene instrucciones para los siguientes grupos de tareas:

• Cargar y almacenar
• Aritmética
• Conversión de tipo
• Creación y manipulación de objetos
• Gestión de la pila de operandos (push / pop)
• Transferencia de control (ramificación)
• Invocación y devolución del método
• Lanzar excepciones
• Simultaneidad basada en monitores

El objetivo es la compatibilidad binaria. Cada sistema operativo host en particular necesita su propia implementación de la JVM y el tiempo de ejecución. Estas JVM interpretan el código de bytes semánticamente de la misma manera, pero la implementación real puede ser diferente. Más complejo que simplemente emular el código de bytes es implementar de manera compatible y eficiente la API central de Java que debe asignarse a cada sistema operativo host.

Estas instrucciones operan en un conjunto de tipos de datos abstractos en lugar de los tipos de datos nativos de cualquier arquitectura de conjunto de instrucciones específica .

Idiomas de JVM

Artículo principal: Lista de lenguajes JVM

Un lenguaje JVM es cualquier lenguaje con funcionalidad que se puede expresar en términos de un archivo de clase válido que se puede alojar en la máquina virtual Java. Un archivo de clase contiene instrucciones de la máquina virtual Java ( código de bytes de Java ) y una tabla de símbolos, así como otra información auxiliar. El formato de archivo de clase es el formato binario independiente del sistema operativo y del hardware que se utiliza para representar clases e interfaces compiladas. ^[6]

Hay varios lenguajes de JVM, ambos lenguajes antiguos portados a JVM y lenguajes completamente nuevos. JRuby y Jython son quizás los puertos más conocidos de los lenguajes existentes, es decir, Ruby y Python respectivamente. De los nuevos lenguajes que se han creado desde cero para compilar en código de bytes Java, Clojure , Apache Groovy , Scala y Kotlin pueden ser los más populares. Una característica notable de los lenguajes JVM es que son compatibles entre sí , de modo que, por ejemplo, las bibliotecas Scala se pueden usar con programas Java y viceversa. ^[7]

Java 7 JVM implementa JSR 292: Soporte de lenguajes tipados dinámicamente ^[8] en la plataforma Java, una nueva característica que admite lenguajes tipados dinámicamente en la JVM. Esta función se desarrolla dentro del proyecto Da Vinci Machine , cuya misión es ampliar la JVM para que admita lenguajes distintos de Java. ^{[9] [10]}

Verificador de bytecode

Una filosofía básica de Java es que es inherentemente seguro desde el punto de vista de que ningún programa de usuario puede bloquear la máquina host o interferir de otro modo de manera inapropiada con otras operaciones en la máquina host, y que es posible proteger ciertos métodos y estructuras de datos que pertenecen a sistemas de confianza. código de acceso o corrupción por código no confiable que se ejecuta dentro de la misma JVM. Además, no se permite que ocurran errores comunes del programador que a menudo conducen a la corrupción de datos o un comportamiento impredecible, como acceder desde el final de una matriz o usar un puntero no inicializado. Varias características de Java se combinan para brindar esta seguridad, incluido el modelo de clase, el montón de recolección de basura y el verificador.

La JVM verifica todo el código de bytes antes de que se ejecute. Esta verificación consta principalmente de tres tipos de comprobaciones:

• Las sucursales están siempre en ubicaciones válidas
• Los datos siempre se inicializan y las referencias son siempre seguras para los tipos
• El acceso a datos y métodos privados o de paquetes privados está estrictamente controlado

Las dos primeras de estas comprobaciones tienen lugar principalmente durante el paso de verificación que se produce cuando se carga una clase y se hace elegible para su uso. El tercero se realiza principalmente de forma dinámica, cuando otra clase accede por primera vez a elementos de datos o métodos de una clase.

El verificador permite solo algunas secuencias de códigos de bytes en programas válidos, por ejemplo, una instrucción de salto (bifurcación) solo puede apuntar a una instrucción dentro del mismo método . Además, el verificador asegura que cualquier instrucción dada opere en una ubicación de pila fija, ^[11] permitiendo que el compilador JIT transforme los accesos a la pila en accesos a registros fijos. Debido a esto, que la JVM sea una arquitectura de pila no implica una penalización de velocidad para la emulación en arquitecturas basadas en registros.cuando se utiliza un compilador JIT. Frente a la arquitectura JVM verificada por código, para un compilador JIT no hay diferencia si recibe registros imaginarios con nombre o posiciones de pila imaginarias que deben asignarse a los registros de la arquitectura de destino. De hecho, la verificación del código hace que la JVM sea diferente de una arquitectura de pila clásica, cuya emulación eficiente con un compilador JIT es más complicada y, por lo general, la realiza un intérprete más lento.

La especificación original para el verificador de código de bytes utilizaba un lenguaje natural que estaba incompleto o incorrecto en algunos aspectos. Se han realizado varios intentos para especificar la JVM como un sistema formal. Al hacer esto, la seguridad de las implementaciones actuales de JVM se puede analizar más a fondo y se pueden evitar posibles vulnerabilidades de seguridad. También será posible optimizar la JVM omitiendo verificaciones de seguridad innecesarias, si se demuestra que la aplicación que se está ejecutando es segura. ^[12]

Ejecución segura de código remoto

Una arquitectura de máquina virtual permite un control muy detallado sobre las acciones que el código dentro de la máquina puede realizar. Se asume que el código es "semánticamente" correcto, es decir, que pasó con éxito el proceso (formal) de verificación del código de bytes, materializado por una herramienta, posiblemente fuera de la máquina virtual. Esto está diseñado para permitir la ejecución segura de código no confiable de fuentes remotas, un modelo utilizado por los subprogramas de Java y otras descargas de código seguro. Una vez verificado el código de bytes, el código descargado se ejecuta en una " caja de arena " restringida , que está diseñada para proteger al usuario de códigos maliciosos o de mal comportamiento. Además del proceso de verificación del código de bytes, los editores pueden comprar un certificado con el que firmar digitalmenteapplets como seguros, dándoles permiso para pedirle al usuario que salga de la caja de arena y acceda al sistema de archivos local, al portapapeles , ejecute piezas de software externas o a la red.

La industria de tarjetas Java ha realizado pruebas formales de verificadores de códigos de bytes (Desarrollo formal de un verificador integrado para códigos de bytes de tarjetas Java ^[13] ).

Intérprete de código de bytes y compilador justo a tiempo

Para cada arquitectura de hardware se necesita un intérprete de código de bytes de Java diferente . Cuando una computadora tiene un intérprete de código de bytes de Java, puede ejecutar cualquier programa de código de bytes de Java, y el mismo programa se puede ejecutar en cualquier computadora que tenga dicho intérprete.

Cuando un intérprete ejecuta el código de bytes de Java, la ejecución siempre será más lenta que la ejecución del mismo programa compilado en el lenguaje de máquina nativo. Este problema se mitiga con compiladores Just-In-Time (JIT) para ejecutar el código de bytes de Java. Un compilador JIT puede traducir el código de bytes de Java al lenguaje de máquina nativo mientras ejecuta el programa. Las partes traducidas del programa se pueden ejecutar mucho más rápidamente de lo que podrían interpretarse. Esta técnica se aplica a las partes de un programa que se ejecutan con frecuencia. De esta manera, un compilador JIT puede acelerar significativamente el tiempo de ejecución general.

No hay una conexión necesaria entre el lenguaje de programación Java y el código de bytes de Java. Un programa escrito en Java se puede compilar directamente en el lenguaje de máquina de una computadora real y los programas escritos en otros lenguajes además de Java se pueden compilar en código de bytes de Java.

El código de bytes de Java está diseñado para ser independiente de la plataforma y seguro. ^[14] Algunas implementaciones de JVM no incluyen un intérprete, sino que consisten solo en un compilador justo a tiempo. ^[15]

JVM en el navegador web

Al comienzo de la vida útil de la plataforma Java, la JVM se comercializó como una tecnología web para crear aplicaciones web enriquecidas . A partir de 2018 ^[actualizar], la mayoría de los navegadores web y los sistemas operativos que combinan los navegadores web no se envían con un complemento de Java , ni permiten la carga lateral de ningún complemento que no sea Flash . El complemento del navegador Java quedó obsoleto en JDK 9. ^[16]

El complemento del navegador NPAPI Java fue diseñado para permitir que la JVM ejecute los llamados subprogramas Java incrustados en páginas HTML. Para los navegadores con el complemento instalado, el subprograma puede dibujar en una región rectangular en la página asignada. Debido a que el complemento incluye una JVM, los subprogramas de Java no están restringidos al lenguaje de programación Java; cualquier idioma destinado a la JVM puede ejecutarse en el complemento. Un conjunto restringido de API permite a los subprogramas acceder al micrófono del usuario o la aceleración 3D, aunque los subprogramas no pueden modificar la página fuera de su región rectangular. Adobe Flash Player , la principal tecnología de la competencia, funciona de la misma manera a este respecto.

En junio de 2015, ^[actualizar]según W3Techs, el uso del subprograma Java y Silverlight había caído al 0,1% cada uno para todos los sitios web, mientras que Flash había caído al 10,8%. ^[17]

JVM e intérpretes de JavaScript

A partir de mayo de 2016, JavaPoly permite a los usuarios importar bibliotecas Java sin modificar e invocarlas directamente desde JavaScript. JavaPoly permite que los sitios web utilicen bibliotecas Java sin modificar, incluso si el usuario no tiene Java instalado en su computadora. ^[18]

Compilación en JavaScript

Con las continuas mejoras en la velocidad de ejecución de JavaScript, combinadas con el mayor uso de dispositivos móviles cuyos navegadores web no implementan soporte para complementos, existen esfuerzos para apuntar a esos usuarios a través de la compilación en JavaScript. Es posible compilar el código fuente o el código de bytes de JVM en JavaScript.

Compilar el código de bytes de JVM, que es universal en todos los lenguajes de JVM, permite construir sobre el compilador existente del lenguaje para el código de bytes. El código de bytes principal de JVM para los compiladores de JavaScript son TeaVM, ^[19] el compilador contenido en Dragome Web SDK, ^[20] Bck2Brwsr, ^[21] y j2js-compiler. ^[22]

Los compiladores líderes de lenguajes JVM a JavaScript incluyen el compilador de Java a JavaScript contenido en Google Web Toolkit , Clojurescript ( Clojure ), GrooScript ( Apache Groovy ), Scala.js (Scala) y otros. ^[23]

Entorno de ejecución de Java

Artículo principal: HotSpot (máquina virtual)

Java Runtime Environment (JRE) lanzado por Oracle es una distribución de software disponible gratuitamente que contiene una JVM independiente ( HotSpot ), la biblioteca estándar de Java ( Java Class Library ), una herramienta de configuración y, hasta su discontinuación en JDK 9, una plugin para el navegador. Es el entorno Java más común instalado en computadoras personales en el factor de forma de computadora portátil y escritorio . Es más probable que los teléfonos móviles, incluidos los teléfonos con funciones y los primeros teléfonos inteligentes que se envían con una JVM, incluyan una JVM destinada a ejecutar aplicaciones dirigidas a la Micro Edition de la plataforma Java. Mientras tanto, la mayoría de los teléfonos inteligentesLas tabletas y otras PC de mano que ejecutan aplicaciones Java tienen más probabilidades de hacerlo mediante la compatibilidad con el sistema operativo Android , que incluye una máquina virtual de código abierto incompatible con la especificación JVM. (En cambio, las herramientas de desarrollo de Android de Google toman los programas Java como código de bytes de Dalvik de entrada y salida , que es el formato de entrada nativo para la máquina virtual en los dispositivos Android).

Rendimiento

Artículo principal: rendimiento de Java

La especificación JVM da mucho margen a los implementadores con respecto a los detalles de implementación. Desde Java 1.3, JRE de Oracle contiene una JVM llamada HotSpot. Ha sido diseñado para ser una JVM de alto rendimiento.

Para acelerar la ejecución del código, HotSpot se basa en la compilación justo a tiempo. Para acelerar la asignación de objetos y la recolección de basura, HotSpot utiliza el montón generacional.

Montón generacional

El montón de la máquina virtual Java es el área de memoria utilizada por la JVM para la asignación de memoria dinámica . ^[24]

En HotSpot, el montón se divide en generaciones :

• La generación joven almacena objetos de corta duración que se crean y se recogen inmediatamente como basura .
• Los objetos que persisten por más tiempo se trasladan a la generación anterior (también llamada generación permanente ). Esta memoria se subdivide en (dos) espacios de Supervivientes donde se almacenan los objetos que sobrevivieron a la primera y siguiente recolección de basura.

La generación permanente (o permgen ) se utilizó para las definiciones de clases y los metadatos asociados antes de Java 8. La generación permanente no formaba parte del montón. ^{[25] [26]} La generación permanente se eliminó de Java 8. ^[27]

Originalmente no había generación permanente, y los objetos y clases se almacenaban juntos en la misma área. Pero como la descarga de clases ocurre con mucha menos frecuencia que la recopilación de objetos, mover las estructuras de clases a un área específica permitió mejoras significativas en el rendimiento. ^[25]

Seguridad

El JRE de Oracle está instalado en una gran cantidad de computadoras. Los usuarios finales con una versión desactualizada de JRE, por lo tanto, son vulnerables a muchos ataques conocidos. Esto llevó a la creencia ampliamente compartida de que Java es intrínsecamente inseguro. ^[28] Desde Java 1.7, JRE de Oracle para Windows incluye la funcionalidad de actualización automática.

Antes de la interrupción del complemento del navegador Java, cualquier página web podría haber ejecutado un subprograma Java, que proporcionaba una superficie de ataque de fácil acceso para sitios web maliciosos. En 2013, Kaspersky Labs informó que el complemento de Java era el método elegido por los delincuentes informáticos. Los exploits de Java se incluyen en muchos paquetes de exploits que los piratas informáticos implementan en sitios web pirateados. ^[29] Los subprogramas de Java se eliminaron en Java 11, lanzado el 25 de septiembre de 2018.

Ver también

• Lista de máquinas virtuales Java
• Comparación de máquinas virtuales Java
• Comparación de máquinas virtuales de aplicaciones
• Manejo automatizado de excepciones
• Rendimiento de Java
• Lista de lenguajes JVM
• Procesador Java
• Common Language Runtime

Referencias

1. "jdk-updates / jdk15u: etiquetas" . Oracle Corporation . Consultado el 27 de enero de 2021 .
2. Bill Venners, Dentro de la máquina virtual Java Capítulo 5
3. "El programa Java Community Process (SM) - JSR: Solicitudes de especificación de Java - detalle JSR # 924" . Jcp.org . Consultado el 26 de junio de 2015 .
4. "El programa Java Community Process (SM) - JSR: Solicitudes de especificación de Java - detalle JSR # 202" . Jcp.org . Consultado el 26 de junio de 2015 .
5. La especificación de la máquina virtual de Java (la primera y la segunda ediciones también están disponibles en línea).
6. "La especificación de la máquina virtual de Java: Java SE 7 Edition" (PDF) . Docs.oracle.com . Consultado el 26 de junio de 2015 .
7. "Preguntas frecuentes - interoperabilidad de Java" . scala-lang.org . Consultado el 18 de noviembre de 2015 .
8. "El programa Java Community Process (SM) - JSR: Solicitudes de especificación de Java - detalle JSR # 292" . Jcp.org . Consultado el 26 de junio de 2015 .
9. "Proyecto de la máquina Da Vinci" . Openjdk.java.net . Consultado el 26 de junio de 2015 .
10. "Nueva característica de JDK 7: soporte para lenguajes escritos dinámicamente en la máquina virtual Java" . Oracle.com . Consultado el 26 de junio de 2015 .
11. "El proceso de verificación" . La especificación de la máquina virtual de Java . Sun Microsystems. 1999 . Consultado el 31 de mayo de 2009 .
12. Freund, Stephen N .; Mitchell, John C. (1999). "Un marco formal para el verificador y lenguaje de código de bytes de Java". Actas de la 14ª conferencia ACM SIGPLAN sobre programación, sistemas, lenguajes y aplicaciones orientados a objetos - OOPSLA '99 . págs. 147-166. CiteSeerX 10.1.1.2.4663 . doi : 10.1145 / 320384.320397 . ISBN  978-1581132380.
13. http://www-sop.inria.fr/everest/Lilian.Burdy/CBR02dsn.pdf
14. David J. Eck, Introducción a la programación con Java , séptima edición, versión 7.0, agosto de 2014 en la sección 1.3 "La máquina virtual de Java"
15. Introducción a Oracle JRockit Archivado el 6 de septiembre de 2015 en la Wayback Machine Release R28 en 2. "Compilación y optimización Just-In-Time"
16. "Oracle desaprueba el complemento del navegador Java, se prepara para su desaparición" . Ars Technica . 28 de enero de 2016 . Consultado el 15 de abril de 2016 .
17. "Tendencias históricas anuales en el uso de lenguajes de programación del lado del cliente, junio de 2015" . W3techs.com . Consultado el 26 de junio de 2015 .
18. Krill, Paul (13 de mayo de 2016). "JavaPoly.js importa el código Java existente y lo invoca directamente desde JavaScript" . InfoWorld . Consultado el 18 de julio de 2016 .
19. "Página de inicio del proyecto TeaVM" . Teavm.org . Consultado el 26 de junio de 2015 .
20. "Dragome Web SDK" . Dragome.com . Consultado el 26 de junio de 2015 .
21. "Bck2Brwsr - APIDesign" . Wiki.apidesign.org . Consultado el 26 de junio de 2015 .
22. Wolfgang Kuehn (decatur). compilador j2js GitHub
23. "Lista de lenguajes que se compilan en JS · jashkenas / coffeescript Wiki · GitHub" . Github.com. 2015-06-19 . Consultado el 26 de junio de 2015 .
24. "Preguntas frecuentes sobre la recolección de basura en la máquina virtual Java de Hotspot" . Sun Microsystems . 6 de febrero de 2003 . Consultado el 7 de febrero de 2009 .
25. Masamitsu, Jon (28 de noviembre de 2006). "Presentando la Generación Permanente" . Consultado el 7 de febrero de 2009 .
26. Nutter, Charles (11 de septiembre de 2008). "Una primera prueba de InvokeDynamic" . Consultado el 7 de febrero de 2009 .
27. "JEP 122: eliminar la generación permanente" . Oracle Corporation . 2012-12-04 . Consultado el 23 de marzo de 2014 .
28. "¿Qué es Java, es inseguro y debo usarlo?" . Lifehacker.com. 2013-01-14 . Consultado el 26 de junio de 2015 .
29. "¿Existe alguna protección contra las vulnerabilidades de Java? | Kaspersky Lab" . Kaspersky.com. 2013-09-09. Archivado desde el original el 4 de abril de 2015 . Consultado el 26 de junio de 2015 .

• Aclaraciones y enmiendas a la especificación de la máquina virtual Java, segunda edición incluye una lista de cambios que se deben realizar para admitir J2SE 5.0 y JSR 45
• JSR 45 , especifica cambios en el formato de archivo de clase para admitir la depuración a nivel de fuente de lenguajes como JavaServer Pages (JSP) y SQLJ que se traducen a Java

Enlaces externos

• La especificación de la máquina virtual de Java
• Cómo descargar e instalar paquetes OpenJDK precompilados
• ¿Cómo instalar Java? (JRE de Oracle)