¿Cuál es la diferencia entre javac y el comstackdor de Eclipse?

¿El comstackdor de Java de Eclipse es solo un envoltorio alrededor del mismo núcleo que el progtwig javac está envuelto, o es un comstackdor separado por completo? Si esto último, ¿por qué iban a reinventar la rueda?

Eclipse ha implementado su propio comstackdor llamado Eclipse Compiler for Java (ECJ).

Es diferente del javac, el comstackdor que se envía con Sun JDK. Una diferencia notable es que el comstackdor de Eclipse le permite ejecutar código que en realidad no se compiló correctamente. Si el bloque de código con el error nunca se ejecuta, su progtwig se ejecutará correctamente. De lo contrario, lanzará una excepción que indica que intentó ejecutar código que no comstack.

Otra diferencia es que el comstackdor de Eclipse permite comstackciones incrementales desde el Eclipse IDE, es decir, todo el código se comstack tan pronto como termine de escribir.

El hecho de que Eclipse viene con su propio comstackdor también es evidente porque puede escribir, comstackr y ejecutar código Java en Eclipse sin siquiera instalar el SDK de Java.

Algunos ejemplos donde se prefiere ECJ sobre javac son:

  • Apache Tomcat usa ECJ para comstackr JSP,
  • IntelliJ IDEA tiene soporte para ECJ, a partir de GNU Compiler for Java (GCJ) 4.3,
  • GCJ se integra con ECJ,
  • Liferay construye con ECJ.

Todos ya han explicado que son diferentes. Aquí hay algunas diferencias en los comportamientos que he notado entre los dos comstackdores. Todos se reducen a un error en (al menos) una de las implementaciones.

Optimización de tiempo de comstackción relacionada

  • Error Eclipse? Encender un nulo con solo el caso predeterminado

Generics type inferrence related

  • Generics comstack y ejecuta en Eclipse, pero no comstack en javac
  • Los comstackdores se comportan de manera diferente con un parámetro nulo de un método genérico

El comstackdor incorporado de Eclipse se basa en el comstackdor Java de IBM. (Tenga en cuenta que Eclipse también comenzó su vida en IBM). Es completamente independiente del comstackdor Java de Sun en el JDK; no es un envoltorio alrededor del javac de Sun.

Jikes ha existido durante mucho tiempo, solía ser mucho más rápido que el comstackdor JDK Java estándar (pero no sé si eso todavía es cierto). En cuanto a por qué IBM quería escribir su propio comstackdor de Java: tal vez por razones de licencia (también tienen su propia implementación de Java).

Es un comstackdor separado por completo. Esto es necesario ya que javac no permite la comstackción de código ligeramente roto, del sitio de eclipse

Un comstackdor incremental de Java. Implementado como un constructor de Eclipse, se basa en la tecnología desarrollada a partir del comstackdor de VisualAge para Java. En particular, permite ejecutar y depurar código que aún contiene errores no resueltos.