¿El comando 'java' compila programas Java?

La mayoría de los sitios web en internet dicen:

"use el javaccomando para compilar un .javaarchivo. Luego ejecútelo usando el javacomando"

Pero hoy intenté ejecutar un programa Java sin javacy obtuve un resultado extraño.

Aquí están los contenidos de un archivo llamado hello.java:

public class Myclass {
 public static void main(String[] args){
    System.out.println("hello world");
  }
}

Entonces corrí:

$ javac hello.java

Lo que me da este error:

hello.java:1: error: class Myclass is public, should be declared in a file named Myclass.java
public class Myclass {
       ^
1 error

Pero cuando lo ejecuto sin el javaccomando, se ejecutó sin ningún error.

$ java hello.java
hello world

¿El javacomando también compila el programa? En caso afirmativo, ¿por qué necesitamos el javaccomando?

La versión de mi java es:

openjdk version "12.0.2" 2019-07-16
OpenJDK Runtime Environment (build 12.0.2+10)
OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode)

Antes de Java 11, para ejecutar su código, primero debe compilarlo, luego puede ejecutarlo. Aquí hay un ejemplo:

javac test.java
java test

Desde Java 11, aún puede hacer javac+ java, o puede ejecutarse javasolo para compilar y ejecutar automáticamente su código. Tenga en cuenta que no .classse generará ningún archivo. Aquí hay un ejemplo:

java test.java

Si corres java -help, verás los diversos usos permitidos. Así es como se ve en mi máquina. El último es con el que se topó: java [options] <sourcefile> [args]que "ejecutará un solo programa de archivo fuente".

$ java -help
Usage: java [options] <mainclass> [args...]
           (to execute a class)
   or  java [options] -jar <jarfile> [args...]
           (to execute a jar file)
   or  java [options] -m <module>[/<mainclass>] [args...]
       java [options] --module <module>[/<mainclass>] [args...]
           (to execute the main class in a module)
   or  java [options] <sourcefile> [args]
           (to execute a single source-file program)

ACTUALIZAR:

Como señaló @BillK, OP también preguntó:

¿Por qué necesitamos el comando javac?

La razón por la que necesitamos javaces crear .classarchivos para que el código se pueda crear, probar, distribuir, ejecutar, compartir, etc., como es hoy. La motivación para JEP 330 fue facilitar las "primeras etapas de aprendizaje de Java y al escribir pequeños programas de utilidad" sin cambiar ningún otro uso existente.

Si está ejecutando Java 11, hay una nueva característica que permite la ejecución de un solo archivo fuente. El compilador de fuente única es más promiscuo en términos de nombre de clase versus nombre de archivo, por lo que así es como puede ejecutar pero no compilar correctamente.

Si está en una versión anterior de Java, entonces su hello.java actual no se compila, debido a errores de compilación, específicamente alrededor del nombre de la clase. Entonces, no hay absolutamente ninguna manera de que llamar a java hello.java compile su código, porque no se compila.

Parece muy probable que estuviera ejecutando algún código compilado previamente al ejecutar el comando java.

Para responder por qué se da este error, el nombre de la clase para el archivo debe coincidir con el del archivo basename.

Tiene dos opciones para que este código funcione para el tradicional javac; javasecuencia:

1. Cambiar el nombre de la clase a public class Helloo

2. Cambiar el nombre hello.javaa myclass.java.

El javaintérprete para Java 11 no impone este requisito. La clase que contiene mainpuede tener cualquier nombre, siempre que sea la primera clase en el archivo. Esto estaba destinado principalmente a facilitar el proceso de aprendizaje para principiantes, y para permitir "scripts java" con el shebang ( ref. ).

Sí, pero no de la manera que probablemente quieras decir.

Cuando utiliza el javaccomando para compilar un archivo .java en un archivo .class, el resultado es algo llamado bytecode. Bytecode es un código de máquina (instrucciones nativas) para una CPU teórica basada en la especificación de Java Virtual Machine.

Esta especificación de CPU virtual es una especie de promedio de tipos de CPU que eran comunes en el momento en que se escribió la especificación. Debido a esto, está cerca de muchos tipos diferentes de CPU, lo que facilita la ejecución de los mismos archivos Java .class en múltiples tipos de CPU.

Cuando Java se lanzó por primera vez, el javacomando leería el archivo .class e interpretaría las instrucciones de bytecode de una en una y luego las asignaría a la instrucción nativa equivalente para la CPU en la que se estaba ejecutando. Esto funcionó pero no fue particularmente rápido. Para mejorar esto, se agregó la compilación Just in Time (JIT) a Java Runtime.

Con JIT, el javacomando toma el código de bytes y lo vuelve a compilar con las instrucciones nativas para la CPU en la que se está ejecutando. Los tiempos de ejecución modernos de Java tienden a comenzar a interpretar el código de bytes mientras compila JIT en segundo plano y cambiar a las instrucciones nativas compiladas cuando está listo y también perfilará la aplicación en ejecución y luego volverá a compilar el código de bytes con una optimización diferente para obtener el mejor rendimiento posible.

EDITAR (para apaciguar a los votantes caídos):

Entonces, en su caso específico (ya que está ejecutando un JRE más nuevo que v11), el código se compila (al menos) dos veces

1. Como un único archivo .java para bytecode
2. A través del compilador JIT, ya que interpreta el código de bytes (aunque para helloWorld podría no tener tiempo para ejecutar ninguno de los códigos nativos compilados)