Los programas de Java se compilan en un lenguaje intermedio llamado Java bytecode . Se puede decir que estos son interpretados por el tiempo de ejecución de Java (en realidad, la máquina virtual de Java), pero creo que es un poco más complicado que eso.

Estoy seguro de que algún código se compila justo a tiempo (JIT) en tiempo de ejecución, lo que significa que el JRE realmente compila parte del código de bytes en el código de máquina real. Los detalles de cuándo hace esto y por qué razones están más allá de mi conocimiento, pero a menudo se hace por razones de rendimiento. Veo que otra respuesta proporciona un enlace a la información JIT para usted.

Como notará en ese enlace de Wikipedia, algunos compiladores como el compilador GNU Java pueden compilar directamente en código de máquina.

También notará que dice que algunos procesadores especiales pueden ejecutar el código de bytes de forma nativa, en cuyo caso no se necesita JVM.

Ah, otra nota: cuando el programa se ejecuta (dentro de una JVM), de hecho es una "instancia de la JVM". Si revisa su lista de procesos, verá que su programa es una instancia de la aplicación java . Entonces, si busca en el Administrador de tareas en Windows o en el Monitor de actividad en Mac o en la lista de ID de proceso en Linux, verá un proceso java ejecutándose para cada uno de los programas Java que inició.

Sí, hasta cierto punto, el JDK (Kit de desarrollo de Java) debe compilar cada uno de los programas de Java y ejecutar el JRE (Java Runtime Environment), que es una herramienta de desarrollo de Java.

Cuando se compila un Java, da como resultado un .jre o .class que no se puede ejecutar directamente en un procesador de computadora de ninguna manera (hay formas de cambiar .jar a .exe), pero tendrá que ejecutarse a través del JVM (Java virtual machine) a través del compilador JIT (just-in-time).

Con este cuadro aquí, entonces, hasta cierto punto, sí, las clases de programas Java "pertenecen" al JRE. Pero definitivamente es más complicado que eso.

Le sugiero que lea más sobre el JIT aquí .

Para darle un giro más simple a esto, la respuesta es: Sí (aunque en realidad te refieres a la JVM en lugar de a la JRE). El programa que ejecuta el sistema operativo es la JVM (máquina virtual Java), y la aplicación Java son los datos que lee ese programa. La JVM es como Microsoft Word y los programas Java son como documentos de Word.

Esta pregunta toca la diferencia esencial entre los lenguajes compilados e interpretados, como se describe bienaquí .

Para usar más la analogía para explicar qué son JVM y JRE... JVM es como el programa Microsoft Word en sí, y JRE es como el programa MS Word más todas las demás cosas, como plantillas, documentos de muestra, fuentes, etc. que se instala junto con él para admitir lo que hace.

Todo esto es para preguntar, ¿todos los programas de Java son simplemente programas de consola java [argument] ?

No eso específicamente , no, porque no todos los programas Java se ejecutan a través de la herramienta java , pero sigue leyendo.

Otra forma de preguntar, ¿son todos los programas Java solo programas/instancias JRE que están leyendo un archivo de clase en particular?

Los programas Java generalmente son ejecutados por una máquina virtual Java (JVM), como la que se encuentra en Java Runtime Environment, sí. Es decir, en la mayoría de las situaciones, el programa Java (la colección de código de bytes de clase y otros recursos que componen el programa, a veces en un archivo .jar / .war / .ear /etc.) se carga y ejecuta mediante una instancia del JVM, que es lanzado por la herramienta java o un contenedor de servlets (o, en el pasado, un contenedor de subprogramas) o algún otro entorno que sepa cómo generar una instancia de JVM.

Por lo general, es así:

1. Los archivos .java se compilan en el código de bytes de Java , normalmente se generan como archivos .class . El código de bytes de Java es un lenguaje de máquina de alto nivel que no depende de una arquitectura de CPU o sistema operativo específico.

2. A veces, los archivos .class (y otros recursos) se agrupan en contenedores (archivos .jar , archivos .war , archivos .ear , etc.).

3. Cuando llega el momento de ejecutar el programa, utiliza la herramienta java o un contenedor de servlet o algún otro tipo de proceso que sepa cómo ejecutar el código de bytes de Java. Estos son específicos de la CPU y el sistema operativo e incorporan o cargan una JVM.

4. El código en la herramienta ( java o contenedor de servlet u otro) carga el código de bytes (desde el archivo .class o similar) y lo pasa a la JVM para que se cree una instancia y se ejecute. Dependiendo de la JVM, eso podría implicar simplemente interpretar el código de bytes, o compilarlo en un código de máquina específico de la CPU y el sistema operativo (compilación "justo a tiempo" [JIT]) y ejecutar eso, o una combinación de los dos. HotSpot JVM de Sun, por ejemplo, realiza al menos dos niveles de compilación JIT dependiendo de si un segmento específico de código se usa lo suficiente como para molestarse en compilarlo y, de ser así, lo suficiente como para justificar una optimización agresiva.

Hay compiladores que compilan el código fuente de Java o el código de bytes de Java en código de máquina para arquitecturas de CPU y sistemas operativos específicos, generando un ejecutable todo en uno, pero lo anterior es el escenario habitual.

Creo que ayuda aquí dar un paso atrás y mirar el panorama general aquí. Cuando ejecuta un programa Java de la forma que describe, se está ejecutando en una máquina virtual. Uno específico que pasa a tener el nombre 'java'.

Sin embargo, hay otras máquinas virtuales que ejecutan Java. Una de las máquinas virtuales más nuevas es GraalVM . No estoy seguro de que sea completamente correcto llamarlo JVM porque (supuestamente) también puede ejecutar otros lenguajes como Python, Ruby, C y C++. Entonces, si ejecuta un programa C ++ en GraalVM, ¿es ese programa C ++ ahora 'solo' una aplicación GraalVM? No lo creo. Para enturbiar aún más las aguas, GraalVM puede compilar programas Java en binarios nativos.

Como una especie de aparte, no hay nada especial en Java con respecto a tener un entorno de tiempo de ejecución. C# (.NET) tiene el CLR que definitivamente y de ninguna manera se basó en las ideas de JVM, por supuesto. CPython tiene un tiempo de ejecución llamado 'python'.

Si estoy ejecutando Windows en una máquina virtual que se ejecuta en Linux, y estoy ejecutando un programa escrito en C ++, ¿Windows ahora es solo un programa que se ejecuta en Linux? Si decimos que sí, ¿qué significa eso para la aplicación C++? ¿Es un programa independiente? ¿Qué pasa con una aplicación C++ que se ejecuta en un contenedor en una máquina virtual que se ejecuta en un servidor en la nube? ¿Es ese programa menos 'real' ejecutándose en esa configuración que cuando se ejecuta en su escritorio?

TLDR: La virtualización es omnipresente en la informática. Definitivamente hay aspectos de la JVM estándar que son distintos de otras tecnologías de virtualización, pero estas son distinciones bastante menores en el gran esquema de las cosas.

Cuando invoca java Main.class dentro de la consola cmd.exe, ¿es realmente su propio programa independiente?

No.

Se siente más como si java es el programa en ejecución y Main.class es solo un argumento dado.

Está.

Esto no es diferente de cualquier otra invocación de línea de comandos: primero el nombre del programa, luego los argumentos.

Generalmente, Java no se "compila" completamente antes de tiempo; está casi compilado a la mitad, y el resultado lo ejecuta la máquina virtual de Java cuando desea ejecutar su programa. La JVM se invoca usando el ejecutable llamado java .

El archivo Main.class no es, en sí mismo, un ejecutable que pueda ejecutar su sistema operativo.

Descargo de responsabilidad: no tengo una máquina con Windows, así que este es el estado de las cosas en Linux.

Todo es extremadamente simple. Aquí está la manera de entender lo que está pasando:

I.

 $ which java /usr/bin/java -> /etc/alternatives/java*

(Esto es para una versión Debian de Linux, como Ubuntu . Otros son similares).

II.

 $gdb /etc/alternatives/java (gdb) list main 93 __initenv = _environ; 94 95 #else /* JAVAW */ 96 JNIEXPORT int 97 main(int argc, char **argv) 98 { 99 int margc; 100 char** margv; 101 int jargc; 102 char** jargv;

Aquí ve una función principal de C simple que acepta parámetros de la línea de comando a medida que los pasa (aunque los argumentos están sujetos a una transformación complicada). La función es la primera que se llama cada vez que invoca su programa Java.

Sirve como un proxy que carga libjvm.so que contiene el código HotSpot y llama a la función específica CreateJavaVM para pasar el control al código HotSpot VM que primero inicializa todos los subsistemas VM (compilador JIT, GC, genera plantillas de intérprete, instala controladores de señal, etc...) y luego llama a la función public static void main suya.

En resumen, invoca un binario regular compilado de forma nativa que sabe cómo ejecutar los programas Java que especificó como argumentos;)

Por supuesto. Esta es la belleza de las computadoras modernas: el código es información.

En los primeros días de las computadoras en la década de 1940, "programar" una computadora significaba conectar cables y reconfigurar el hardware físico. Un avance innovador fue la máquina de von Neuman , donde un programa se almacena como datos, y la computadora luego lee esos datos y toma diferentes medidas según el contenido de esos datos.

Hoy todos los programas se manipulan como datos. Cuando escribe un programa en, digamos, C#, eso es solo un montón de cadenas de texto. Luego ejecuta un "compilador" para leer esas cadenas de texto y escupir lenguaje de máquina, probablemente en un lenguaje que pueda ser entendido por el procesador donde ejecutó el compilador. Pero no necesariamente: hay "compiladores cruzados", en los que se compila un programa en la máquina X para que se ejecute en la máquina Y. (Esto es especialmente útil cuando se inventa una nueva computadora. De lo contrario, ¿qué lenguaje usaríamos para escribir un compilador para una nueva computadora? computadora Y, cuando todavía no hay ningún compilador que se ejecute en Y?)

Seguramente copia regularmente archivos de programa de una computadora a otra o de una carpeta a otra en la misma computadora. Obtiene listados de directorios que incluyen archivos de programa. Etc. Los trata como datos.

Entonces, hoy en día existen básicamente tres tipos de lenguajes: lenguajes compilados, lenguajes interpretados y lenguajes de máquinas virtuales.

Con un lenguaje compilado, el programa que escribe se traduce a código de máquina que se puede ejecutar directamente.

Con un lenguaje interpretado, como algunos BASIC , un intérprete lee su código fuente y descubre qué hacer con él sobre la marcha.

Con un lenguaje de máquina virtual, como Java, su programa se traduce a "código de bytes". Este código de bytes es luego leído y procesado por la "máquina virtual". Básicamente, el código de bytes es como el lenguaje de máquina para una computadora imaginaria: no hay (necesariamente) una computadora que pueda ejecutar el código de bytes directamente, pero escribimos un intérprete que lo procesa y da los mismos resultados que si existiera tal " verdadero" lenguaje de máquina.

Una ventaja del código de bytes, y uno de los principales puntos de venta de Java cuando se introdujo por primera vez, es que una vez que implementa una máquina virtual en una computadora, puede ejecutar cualquier programa escrito en ese lenguaje. Ni siquiera necesita volver a compilar. Solo ejecútalo. Entonces, si mañana alguien inventa una computadora Fwacbar 2020 con un conjunto de instrucciones totalmente nuevo que no se parece en nada a Pentium ni a ninguna CPU existente, y escribe una máquina virtual Java para esa computadora, puede ejecutar cualquier programa Java en ella.

Las personas que escribieron el programa Java no necesitan volver a compilar para la nueva computadora. No tienen que poner su código fuente a disposición de nadie. Ni siquiera tienen que saber que existe la nueva computadora. Su programa Java simplemente funcionará en la nueva computadora. (Suponiendo que la JVM no tenga errores, por supuesto, pero se podría decir eso de cualquier cosa).

La gente de Java comercializó con el lema "escribe una vez, ejecuta en cualquier lugar". Una vez escribí un programa Java en Windows y también lo probé en Linux. Pero alguien con una Mac compró una copia y pudo ejecutarla en su Mac con solo un poco de ayuda mía para instalarla correctamente.

Además de otras respuestas, quizás sería útil formularla de esta manera:

Hay muy pocos programas (en PC) que solo ejecutan instrucciones puras de máquina y solo dependen del hardware. En su mayoría son cargadores de arranque, que (eventualmente) inician algún tipo de sistema operativo.

El sistema operativo generalmente le permite compilar sus programas en instrucciones de máquina y usarlas, pero requiere que el código de máquina de su programa cumpla con una plantilla particular ( EXE , ELF , etc. formato de archivo binario), que el sistema operativo particular reconoce, y a cambio para quedarse con esa plantilla, el sistema operativo en realidad "sabe" cómo ejecutarlo y proporciona muchos de sus recursos y bibliotecas que sus programas pueden llamar y usar (redes, acceso al sistema de archivos, etc.).

Sin un sistema operativo, no se iniciaría ningún programa de espacio de usuario. Esa es la razón por la cual los programas compilados de instrucciones de máquina generalmente solo se pueden usar en su sistema operativo de destino.

Los sistemas de compilación de código de bytes le permiten ir a la mitad. Parte del trabajo de traducir su programa a código de máquina se realiza durante la compilación. Pero el resultado no está en un formato que sea compatible con los sistemas operativos habituales (Windows, Linux, etc.). Es un código de bytes, que requiere un entorno adicional además del sistema operativo, para ejecutar su código. Java es uno de esos lenguajes.

La ventaja del código de bytes es que generalmente se puede usar sin cambios en cualquier máquina que tenga el entorno de código de bytes adecuado. Una especie de sistema de "compilar una vez, ejecutar en todas partes", pero también hay advertencias.

Y finalmente tenemos sus idiomas interpretados , que requieren que inicie el intérprete de idioma completo cada vez que inicie el programa, y que el intérprete haga todo el trabajo cada vez. El código fuente de su programa generalmente está disponible para su inspección y cambio en cualquier momento, y los cambios se pueden hacer sin un proceso de recompilación (a veces lento). Además, los programas de lenguaje interpretado con frecuencia no tienen que modificarse cuando se usan en máquinas de arquitectura diferente.

Como se puede imaginar, cuanto más entorno se necesita para iniciar el programa cada vez, más lenta puede ser la respuesta del programa. Sin embargo, para las computadoras modernas y los intérpretes modernos, la diferencia en muchos casos no es tan dramática como solía ser. Aún así, para muchos programas intensivos en recursos, la compilación en código de máquina ejecutable (nivel de sistema operativo) sigue siendo la preferida o, a veces, la única forma de que el programa pueda funcionar de manera aceptable.

Además, como han señalado algunas respuestas y comentarios, las líneas se han desdibujado entre estos tres modos, algunos intérpretes codifican byte, se han desarrollado algunas máquinas que pueden entender el código de byte directamente. Sin embargo, sigue siendo útil saber qué se necesita generalmente para ejecutar qué tipo de código.

Esto es cuestión de perspectiva:

• Desde la perspectiva del shell, java.exe es el programa y Main.class un argumento.

• Desde la perspectiva del sistema operativo, el proceso comienza ejecutando java.exe , lee la clase principal, genera nuevo código nativo, se lo agrega a sí mismo y pasa la mayor parte de su tiempo ejecutando ese código generado (desde esa perspectiva, Java El programa no está "en la parte superior" sino "lado a lado" con la JVM).

• Desde la perspectiva del programador de Java, Main.class es el programa y JRE es un entorno de tiempo de ejecución necesario para ejecutar ese código en una plataforma en particular.

Vale la pena señalar que existe una flexibilidad significativa en la forma en que se carga el JRE:

• Puede ejecutar java.exe para cargar la JVM en un nuevo proceso.
• Cualquier proceso puede cargar jvm.dll para incrustar una JVM (y programas Java) en su propio proceso. Por ejemplo, LibreOffice Base carga jvm.dll (o jvm.so, según la plataforma) para alojar el programa java HSQLDB. Desde la perspectiva del sistema operativo, ese proceso contendrá código de LibreOffice Base, la JVM y el código generado en tiempo de ejecución para HSQLDB.

En resumen, si un programa Java es "simplemente java.exe" depende de su perspectiva y de cómo se inicie el programa Java. Dado que el mismo programa puede iniciarse de muchas maneras diferentes y considerarse desde una variedad de perspectivas, un "programa Java" no es, en general, un sinónimo de "comando de shell", "ejecutable nativo" o "proceso".