-
Notifications
You must be signed in to change notification settings - Fork 66
/
incompatibilities.html
65 lines (62 loc) · 3.25 KB
/
incompatibilities.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">
<head>
<meta name="copyright" content="Copyright (c) 2023 IBM Corporation and others. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../../book.css" charset="ISO-8859-1" type="text/css">
<title>Incompatibilities between Eclipse JDT 4.26 and 4.27</title>
</head>
<body>
<h1>Incompatibilities between Eclipse JDT 4.26 and 4.27</h1>
<p>
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.
</p>
<!-- ############################################## -->
<h3><a name="ecj_split">Note about ECJ separation from JDT Core</a></h3>
<p>
ECJ (Eclipse compiler for Java) code is moved from <code>org.eclipse.jdt.core</code>
to dedicated <code>org.eclipse.jdt.core.compiler.batch</code> bundle and will be
deployed as a separated bundle.
The <code>org.eclipse.jdt.core.compiler.batch</code> is now included in SDK
as a regular Eclipse bundle and can be compiled / deployed / used separately
from <code>org.eclipse.jdt.core</code> bundle.
All of ECJ packages are re-exported by <code>org.eclipse.jdt.core</code>, therefore
from OSGI point of view, all 3rd party code that used some compiler related API
from <code>org.eclipse.jdt.core</code> doesn't require any change.
The <code>org.eclipse.jdt.core.compiler.batch</code> bundle itself doesn't have any dependencies
and so can be used in Eclipse products that do not use workspace concepts.
</p>
<p>
However, no change is without side effects.
</p>
<p>
<b>Known problems with the split of the ECJ from core bundle</b>
</p>
<ol>
<li>
As part of the <code>org.eclipse.jdt.core.compiler.batch</code> code separation from
<code>org.eclipse.jdt.core</code>, the two fragments of <code>org.eclipse.jdt.core</code> -
<code>org.eclipse.jdt.compiler.apt</code> and <code>org.eclipse.jdt.compiler.tool</code>
were merged into <code>org.eclipse.jdt.core.compiler.batch</code>.
So if some target definition, launch configuration or build file referenced the two fragments, these
references can and should be removed now.
</li>
<li>
Another issue might affect standalone (non OSGI based) applications that
were using <code>org.eclipse.jdt.core</code> as a "simple" Java library
(which jdt.core never was).
So for example code that had <code>org.eclipse.jdt.core_XYZ.jar</code> on
classpath and tried to call this outside Eclipse:
<pre>ASTParser parser = ASTParser.newParser(AST.getJLSLatest());</pre>
would fail now with <pre>NoClassDefFoundError: org.eclipse.jdt.internal.compiler.env.ICompilationUnit</pre>
because <code>org.eclipse.jdt.core.dom.ASTParser</code> uses internally ECJ
APIs and they are now ... surprise ... moved to <code>org.eclipse.jdt.core.compiler.batch</code>
jar. To fix this error, <code>org.eclipse.jdt.core.compiler.batch</code> library
should be added to the application classpath.
</li>
</ol>
<!-- ############################################## -->
</body>
</html>