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

@Bart, el compilador de Eclipse funciona lo suficientemente bien para compilaciones de lanzamiento empresarial.

17 de junio de 2010 a las 12:51

@jinguy No estoy de acuerdo con que deba usar el compilador Eclipse para los lanzamientos. Como indicó en la respuesta, puede compilar código con errores, no quiere cosas como public void foo() { throw new Error (“Problema de compilación no resuelto: \n\tFOOBAR no se puede resolver\n”); } para que aparezca en mi código de producción.

28 de septiembre de 2011 a las 13:18

@Matthew Farwell No dijo que deberías, pero que puedes. Y si alguna vez crea una compilación con errores, entonces algo está mal con su proceso de compilación en primer lugar.

14 de noviembre de 2011 a las 22:28

Tenga en cuenta que incrustar ECJ en su aplicación permite que su programa se ejecute bajo un JRE en lugar de requerir un JDK.

4 de junio de 2015 a las 8:07

@MatthewFarwell para cerrar un ciclo aquí: para versiones de lanzamiento, se recomienda simplemente no especificar el argumento del compilador -proceedOnError y simplemente no producirá archivos .class desde la fuente con errores.

01/08/2015 a las 19:58

En realidad, me di cuenta de esta diferencia después de una larga noche: Eclipse estaba informando un error sobre algo que me parecía legal (no recuerdo qué), en mi desesperación (apenas podía mantenerme despierto) simplemente alimenté el código a javac y entonces funcionó sin problemas! Descubrí en Google que tenía que actualizar el JDT para solucionar ese problema.

18 de junio de 2010 a las 15:18

He encontrado una serie de diferencias entre los compiladores que manejan genéricos en casos difíciles. Aquí hay dos preguntas sobre las que hice aquí en caso de que desee agregarlas a su respuesta: stackoverflow.com/questions/13501836/… stackoverflow.com/questions/13980552/…

18 de marzo de 2013 a las 10:13

Las clases anónimas nunca son estáticas según JLS, pero se pueden declarar en un ámbito estático. Cuando se usa la reflexión para preguntar si dicha clase es estática, el código generado por ECJ dice que no, mientras que el de javac dice que si. Publicación relacionada aquí.

18/04/2013 a las 14:30

Cualquier diferencia semántica en el bytecode emitido es un error en cualquiera de las implementaciones. Esto no es muy interesante en mi opinión. Puedo producir fácilmente una larga lista de tales “diferencias” simplemente enumerando los errores abiertos de javac y ecj.

17/10/2014 a las 19:37

FYI, Netbeans no sufre de tales “diferencias” ya que usa la API interna de javac para hacer todo lo que hace EJC.

19 mayo 2015 a las 13:16

ellos no De Verdad escribir su propio compilador de Java. Eclipse tiene un largo linaje que se remonta a Visual Age para Smalltalk, incluso antes de que Java existiera. Dado que los dos idiomas son en realidad algo similares, simplemente adaptaron su tecnología existente. El compilador de Sun tampoco es adecuado para su uso en un IDE, especialmente en un IDE de estilo Smalltalk incremental como el Visual Age para Java original, ya que siempre quiere compilar archivos completos. El compilador de IBM puede compilar incrementalmente solo los fragmentos que han cambiado. Incluso puede compilar fragmentos que ni siquiera son Java legales, que se utilizan en el

17 de junio de 2010 a las 14:35

Libro de recuerdos de Eclipse donde simplemente puede escribir fragmentos de código, resaltarlos y ejecutarlos, sin tener que ponerlos en una clase, un método principal o incluso en un método en absoluto.

17 de junio de 2010 a las 14:36

@JörgWMittag En realidad, la API interna de javac (como la usa Netbeans) se puede usar para lograr los mismos objetivos.

19 mayo 2015 a las 13:15

@AleksandrDubinsky: ¿Qué tan bien funcionó eso en 1997, cuando se lanzó Visual Age para Java?

3 de febrero de 2019 a las 10:22