diff --git a/4.27/jdt.html b/4.27/jdt.html index 64088b2150..daf7646924 100644 --- a/4.27/jdt.html +++ b/4.27/jdt.html @@ -50,6 +50,80 @@
+ 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 +
++
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.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.
+