Factsheet
Videos
Eclipse has its own Java compiler, which is called [JDT Core][1] (org.eclipse.jdt.core). The compiler itself is included in the org.eclipse.jdt.core plugin. Eclipse won't use any user installed JDK. Instead it uses its own JDT core to compile Java program due to the following primary reason:
The primary reason is that JDT core has the ability of incremental compilation, which means that it incrementally compiles changes in your code (this is also why Eclipse does not need a compilation button because it automatically compiles when changes are detected). But Oracle's JDK does not support incremental compilation.
Does Eclipse's JDT core compiler include a JRE?
- No. JDT core is different from JDK. JDT core is a compiler not including a JRE (while JDK includes JRE). This is why we must specify installed JREs for Eclipse to start.
In summary, Eclipse uses its own JDT core as the Java compiler. The JDT core compiler does not have a JRE. So Eclipse requires user installed JRE to run the .class code.
References:
[1] JDT Plug-in Developer Guide, http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%2Fguide%2Fjdt_api_compile.htm
[2] JDT Core Component, https://www.eclipse.org/jdt/core/
[3] How does Eclipse compile classes with only a JRE? How does Eclipse compile classes with only a JRE?
In contrast to other Java IDEs, Eclipse uses its own incremental compiler written in Java. It can display more warnings and errors than javac. Both, the Eclipse compiler and javac implement the Java Language Specification. There are corner cases where the two compilers produce different bytecode or one of them fails (e. g. see this Stack Overflow question).
The Eclipse compiler requires at least a JRE for the class files, e. g. java/lang/String.class. A JDK is only to see the source code, but not required by the Eclipse compiler.
So far Eclipse was not shipped with a JRE (see Eclipse bug 506244). But this could change soon after the Java virtual machine OpenJ9 became an Eclipse project.
You can un-check the build automatically in Project menu and then build by hand by type Ctrl + B, or clicking an icon the appears to the right of the printer icon.
You will need to go to Project->Clean...,then build your project. This will work, even when your source code does not contain any main method to run as an executable program. The .class files will appear in the bin folder of your project, in your workspace.
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.
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
- Eclipse bug? Switching on a null with only default case
Generics type inferrence related
- Generics compiles and runs in Eclipse, but doesn’t compile in javac
- Compilers behave differently with a null parameter of a generic method
It would be normal to have a separate build process (e.g. with something like Maven) that does not use the Eclipse compiler which is responsible for producing the final deployable artifacts. For example, in all of my Eclipse Java projects I use:
- The built-in Eclipse compiler for quick testing (JUnit), debugging and local execution
- Maven to do the "real" builds (full test suite, building deployment artifacts etc.). Here Maven is using the version of the Java compiler that comes with my local JDK.
- TravisCI (via GitHub) to do continous integration testing (which also uses Maven, but on remote machines)
You could in theory use the compiled Eclipse class files in production if you want - nothing to stop you packaging these up yourself and deploying them. But this would be a strange thing to do, since it would take a bit of effort and lose you the benefits of having a proper build setup.
P.S. if you want to get good that this stuff then I strongly suggest you invest in learning Maven. It's a steep learning curve but really worth it in the long run.
I've never seen the eclipse compiler's output being used for production in any professional or open source project. It probably would work just fine, but it's just not what you do.
Part of the reason is probably that eclipse is not quite as dominant as Visual Studio, another that build tools like Ant and Maven have always existed separate from the IDE, and there is a strong expectation to use them for build automation.