Is Eclipse's Java compiler just a wrapper around the same core that the javac program is wrapped around, or is it a separate compiler altogether? If the latter, why would they reinvent the wheel?
What is the difference between javac and the Eclipse compiler?
Eclipse has implemented its own compiler called as Eclipse Compiler for Java (ECJ).
It is different from the javac, the compiler that is shipped with Sun JDK. One notable difference is that the Eclipse compiler lets you run code that didn't actually properly compile. If the block of code with the error is never ran, your program will run fine. Otherwise, it will throw an exception indicating that you tried to run code that doesn't compile.
Another difference is that the Eclipse compiler allows for incremental builds from within the Eclipse IDE, that is, all code is compiled as soon as you finish typing.
The fact that Eclipse comes with its own compiler is also apparent because you can write, compile, and run Java code in Eclipse without even installing the Java SDK.
A few examples where ECJ is preferred over javac is:
- Apache Tomcat uses ECJ to compile JSPs,
- IntelliJ IDEA has support for ECJ, as of GNU Compiler for Java (GCJ) 4.3,
- GCJ integrates with ECJ,
- Liferay builds with ECJ.
Ok, but if you want to make a release build, which is better to use? –
Effort
@Bart, the Eclipse compiler works well enough for enterprise release builds. –
Hellebore
If you are compiling OSGi bundles instead of regular java, then the Eclipse compiler is more correct because it allows specifying package access rules. PDE will manage these access rules for you to match the OSGi runtime classloaders. bugs.eclipse.org/bugs/show_bug.cgi?id=106631 provides an example of problems that can happen without these rules. –
Takeoff
@jinguy I disagree that you should use Eclipse compiler for releases. As you stated in the answer, it can compile code with errors, you don't want stuff like public void foo() { throw new Error("Unresolved compilation problem: \n\tFOOBAR cannot be resolved\n"); } to appear in my production code. –
Shamblin
@Matthew Farwell He didnt say you should, but that you can. And if you ever create a build with errors in it, then something is wrong with your build process in the first place. –
Tersanctus
JasperReports prefers ECJ over javac to compile reports if it's available. –
Procreant
Also do see the next answer https://mcmap.net/q/103703/-what-is-the-difference-between-javac-and-the-eclipse-compiler it has way more info. –
Faustinafaustine
No one mentioned Jikes? –
Faustinafaustine
Note that embedding ECJ in your application allows your program to run under a JRE instead of requiring a JDK. –
Thorley
@MatthewFarwell to close a loop here: for release builds you're advised to simply not specify the compiler argument
-proceedOnError and it will simply not produce .class files from source with errors. –
Fabiolafabiolas i see JDT, what is JDT? help.eclipse.org/neon/… –
Delocalize
Everyone has already explained that they're different. Here are some difference in behaviors I've noticed between the two compilers. They all boil down to a bug in (at least) one of the implementations.
Compile-time optimization related
Generics type inferrence related
Actually I knew about this difference after a long night: Eclipse was reporting an error about something that to me seemed legal (I don't remember what), in my desperation (I barely could stay awake) I just feed the code to javac and then it worked smoothly! I found in Google that I had to upgrade the JDT in order to get the fix for that issue. –
Traveller
I've found a number of differences between the compilers handling of generics in difficult cases. Here are two I made questions about on here in case you want to add them to your answer: #13502336 #13981052 –
Skilling
Anonymous classes are never static according to the JLS but they can be declared in static scope. When using reflection to ask if such a class is static, ECJ's generated code says no while javac's says yes. Related post here. –
Grantley
Any semantical difference in the emitted bytecode is a bug in either implementation. This is not very interesting in my opinion. I can easily produce a long list of such "differences" by just listing the open bugs from javac and ecj. –
Sear
FYI, Netbeans doesn't suffer from any such "differences" since it uses javac's internal API to do everything that EJC does. –
Abroad
Oddly enough, I came here for a precisely opposite reason? I have an instance where the Eclipse compiler balks at a faulty line of code with Generics, but javac lets it go. (JDK1.8) –
Scup
Eclipse's built-in compiler is based on IBM's Jikes java compiler. (Note that Eclipse also started its life at IBM). It is completely independent of Sun's Java compiler in the JDK; it is not a wrapper around Sun's javac.
Jikes has existed for a long time, it used to be a lot faster than the standard JDK Java compiler (but I don't know if that's still true). As to why IBM wanted to write their own Java compiler: maybe because of licensing reasons (they also have their own Java implementation).
They didn't really write their own Java compiler. Eclipse has a long lineage back to Visual Age for Smalltalk, before Java even existed. Since the two languages are actually somewhat similar, they simply adapted their existing technology. Sun's compiler is also completely unsuitable for use in an IDE, especially in an incremental Smalltalk-style IDE like the original Visual Age for Java since it always wants to compile whole files. IBM's compiler can incrementally compile only the fragments that have changed. It can even compile snippets that aren't even legal Java, which is used in the –
Wellbeloved
Eclipse scrapbook where you can simply write snippets of code, highlight them and run them, without having to put them into a class, a main method, or even into a method at all. –
Wellbeloved
@JörgWMittag Actually, javac's internal API (as used by Netbeans) can be used to achieve all of the same goals. –
Abroad
@AleksandrDubinsky: How well did that actually work in 1997, when Visual Age for Java was released? –
Wellbeloved
It is a separate compiler altogether. This is needed as javac doesn't allow compilation of slightly broken code, from the eclipse site
An incremental Java compiler. Implemented as an Eclipse builder, it is based on technology evolved from VisualAge for Java compiler. In particular, it allows to run and debug code which still contains unresolved errors.
Why would you want the the compilation of "slightly" broken code? –
Scup
@SteveCohen: Because you want the compiler to provide syntax highlighting, semantic highlighting, refactoring support, type checking, code completion, hints, and all the other things a compiler does while you are writing your code, and while you are writing your code, it is more or less by definition incomplete (otherwise, why are you still writing it?) An IDE that only works at the very end of the project, when everything has already been implemented, would be quite useless. –
Wellbeloved
© 2022 - 2024 — McMap. All rights reserved.