So far Eclipse did not change incompatibly between 4.26 and 4.27 in ways that affect plug-ins. Plug-ins that ran on 4.26 should run on 4.27 without any problems.
ECJ (Eclipse compiler for Java) code is moved from org.eclipse.jdt.core
to dedicated org.eclipse.jdt.core.compiler.batch
bundle 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
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.
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.ICompilationUnitbecause
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.