Eclipse jdt java compiler

Historically the code for ECJ was always in the same org.eclipse.jdt.core project that also contained the code for the Java support in the IDE, just in a different source folder. The well known standalone ECJ compiler library that could be used outside of Eclipse (for compilation with external tooling) was generated out of this core bundle at build time and was not included in the default SDK (because it contained subset of packages and classes provided by org.eclipse.jdt.core ).

This lead to few issues, with both Eclipse / standalone use of the ECJ compiler. The (non-JDT) code inside Eclipse that required «default» javax.tools.JavaCompiler API implementation and had no need for full JDT / workspace support was not able to use org.eclipse.jdt.core without pulling in org.eclipse.core.resources bundle and so the dependency to the workspace. Another interesting side effect of hosting ECJ code next to IDE code inside same org.eclipse.jdt.core bundle was that developers couldn’t see if the ECJ code per mistake got some dependency to the IDE.

To resolve these (and other) problems, the ECJ code is moved from org.eclipse.jdt.core to dedicated org.eclipse.jdt.core.compiler.batch project and will be deployed as a separated bundle. The org.eclipse.jdt.core.compiler.batch is now included in SDK as a regular Eclipse bundle and can be compiled / deployed / used separately from org.eclipse.jdt.core bundle. All of ECJ packages are re-exported by org.eclipse.jdt.core , therefore from OSGI point of view, all 3rd party code that used some compiler related API from org.eclipse.jdt.core doesn’t require any change. The org.eclipse.jdt.core.compiler.batch bundle itself doesn’t have any dependencies and so can be used in Eclipse products that do not use workspace concepts.

However, no change is without side effects.

Known problems with the split of the ECJ from core bundle

As part of the org.eclipse.jdt.core.compiler.batch code separation from org.eclipse.jdt.core , the two fragments of org.eclipse.jdt.core — org.eclipse.jdt.compiler.apt and org.eclipse.jdt.compiler.tool were merged into org.eclipse.jdt.core.compiler.batch . So if some target definition, launch configuration or build file referenced the two fragments, these references can and should be removed now.
Another issue might affect standalone (non OSGI based) applications that were using org.eclipse.jdt.core as a «simple» Java library (which jdt.core never was). So for example code that had org.eclipse.jdt.core_XYZ.jar on classpath and tried to call this outside Eclipse:

ASTParser parser = ASTParser.newParser(AST.getJLSLatest());

NoClassDefFoundError: org.eclipse.jdt.internal.compiler.env.ICompilationUnit

JUnit

For example, in the following project, selecting the package test and right-clicking to Run as > JUnit Plug-in Test

Before

Java Editor

To set the new option, go to: Preferences > Java > Editor > Code Minings

Support has been added in Eclipse to recognize the inline version of the tag and show the proper Javadoc hover.

For details on the inline @return tag, see: Javadoc Comment Spec

JDT Developers

All four views are actually not new, however they were previously only available for installation via Eclipse Marketplace and not included in the SDK itself. Now they are shipped with SDK package and also will be available for installation in other packages via https://download.eclipse.org/eclipse/updates/latest/ update site.

Bytecode and Bytecode Reference views are of general use for advanced Java developers interested how the Java code compiled to the class files, independently if the class file was compiled by Eclipse or by other Java compiler.
Abstract Syntax Tree and Java Element views are showing JDT internal representation of the Java code and are useful mostly for JDT developers only.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

License

eclipse-jdt/eclipse.jdt.core

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

When we have too many operands in a String concat expression, the StringConcatFactory hits the 200 arguments limit and crashes. To avoid this, we wrap every 190 arguments into a StringConcatFactory#makeConcatWithConstants() instead of keeping them in the stack. This way, we can accommodate thousands of operands (to be precise 190x199) before hitting the limit.

Git stats

Files

Failed to load latest commit information.

README.md

This is the core part of Eclipse’s Java development tools. It contains the non-UI support for compiling and working with Java code, including the following:

an incremental or batch Java compiler that can run standalone or as part of the Eclipse IDE
Java source and class file indexer and search infrastructure
a Java source code formatter
APIs for code assist, access to the AST and structured manipulation of Java source.

For more information and important links, refer to the JDT wiki page or the JDT project overview page.

Latest nightly, milestone and release SDK and ECJ builds are available at https://download.eclipse.org/eclipse/downloads/
Weekly maven snapshot builds are available at https://repo.eclipse.org/content/repositories/eclipse-snapshots/

Please bear in mind that this project is almost entirely developed by volunteers. If you do not provide the implementation yourself (or pay someone to do it for you), the bug might never get fixed. If it is a serious bug, other people than you might care enough to provide a fix.

Источник

Why does Eclipse use its own Java compiler?

If you are new to Java development with Eclipse IDE, you may be surprised that Eclipse doesn’t use javac – the Java compiler provided by JDK. Instead, Eclipse implements its own Java compiler – based on the Java Language Specification (JLS). There are some good reasons that Eclipse makes use of its own Java compiler:

1. Eclipse Java compiler is an incremental Java builder

The Java compiler built in Eclipse is a part of JDT Core component (JDT: Java Development Tool). An incremental compiler automatically compiles code when changes are detected. It doesn’t compile the whole project’s code. It compiles only the changes you have made (incrementally), giving fast response to programmers.

In contrast, javac does not support incremental compilation. If Eclipse uses javac, programmers will experience slow response for changes they have made, which decreases productivity.

Eclipse Java compiler requires JRE to run compiled byte code, so a JRE is enough to use Eclipse IDE – JDK is not necessary.

2. Eclipse Java compiler allows customization of error and warning messages

Eclipse Java compiler may produce more warnings and errors than javac, which is useful for programmers. You can customize errors and warnings for various Java coding issues.

In Eclipse, go to Window > Preferences > Java > Compiler > Errors/Warnings – then you can see what you can customize:

For example, if Value of local variable is not used, you can instruct the compiler to show an error, warning, info or ignore it.

3. Eclipse Java compiler allows slightly broken code to run

The incremental compiler in Eclipse allows to run a Java program even it still contains unresolved errors. For example, you have error in a method and you attempt to run the program, Eclipse will show a warning message like this:

Click Proceed to run the program anyway. This feature is useful if the unresolved errors do not relate to the code you want to test.

4. Eclipse Java compiler vs. javac compiler

Since Eclipse Java compiler and javac compiler are different, they usually produce different error/warning message for the same issue. Consider this line of code:

Type mismatch: cannot convert from String to int

error: incompatible types: String cannot be converted to int

However, both Eclipse Java compiler and javac implement the Java Language Specification (JLS), the bytecode they produce is almost the same. Except for some corner cases they may produce different bytecode or code compiles with Eclipse but not compiles with javac.

So via this post, I hope you understand why Eclipse uses its own Java compiler and the benefits.

About the Author:

Nam Ha Minh is certified Java programmer (SCJP and SCWCD). He started programming with Java in the time of Java 1.4 and has been falling in love with Java since then. Make friend with him on Facebook and watch his Java videos you YouTube.

Add comment

Comments

Interestingly javac’s and the Eclipse Compilers outputs aren’t as identical as you’d expect or hope for. People should be aware that there are substantial quality issues affecting the output from javac. The JVM is able to filter out the majority of javac’s verbose/redundant byte code.

Источник

Eclipse jdt java compiler