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.