Skip to main content

Java development tools

Eclipse compiler for Java (ECJ)
ECJ separated from JDT Core

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());
    would fail now with 
    NoClassDefFoundError: org.eclipse.jdt.internal.compiler.env.ICompilationUnit
    because org.eclipse.jdt.core.dom.ASTParser uses internally ECJ APIs and they are now ... surprise ... moved to org.eclipse.jdt.core.compiler.batch jar. To fix this error, org.eclipse.jdt.core.compiler.batch library should be added to the application classpath.

JUnit
Launch JUnit tests in subpackages Previously, if one selected a package in the explorer that contained JUnit tests and subpackages that also contained JUnit tests, only the tests directly owned by the package would be run. The functionality has been enhanced so that JUnit tests in subpackages will be found by the JUnitLauncher and launched as well.

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

Before

will result in:

JUnit results

Java Editor

New code mining preference In the past, the code minings for method references used the Search preferences page setting: Ignore potential matches to determine if inexact matches should be filtered out. By default, this setting is false and so code mining could result in a number of entries that were only potential matches. To make this more intuitive and to change the default behavior, the Code Mining preference page has been enhanced to have its own setting: Ignore inexact matches which by default is set to true.

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

New Code Mining Preference
Javadoc inline @return As of Java 16, the Javadoc @return tag can be specified as an inline tag (with curly braces) in a method's Javadoc comment. When used it generates both the method description and the Returns section of the Javadoc for the method. It is specified as follows: {@return <return description>}. The generated Javadoc will show: Returns <return description>. for the method's main description and will use the same description to generate the Returns section. In the case where both the inline @return tag and block @return tag are specified, the new inline tag will override.

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

Using new inline return tag

JDT Developers
Four new views added to SDK Following four new Java / JDT related views are shipped now by default with the Eclipse SDK:
  1. Abstract Syntax Tree
  2. Bytecode
  3. Bytecode Reference
  4. Java Element

List of views

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.

Views with some content

Previous Up Next

Back to the top