## What's New in Eclipse 4.27 (JDT)

Here are descriptions of some of the more interesting or significant changes made to the Java development tools (JDT) for the 4.27 release of Eclipse. They are grouped into:

- Java Compiler
- JUnit
- Java Editor
- JDT Developers

See also the Eclipse Platform What's New document for changes in the Platform.

We also recommend to read the Tips and Tricks.

## 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

will result in:

## 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

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

## 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`

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.