I propose we skip Eclipse 2021-09 and go directly to Eclipse 2021-12 2022-06.
While Eclipse 2021-12 also supports Java 17, the next Java LTS release, this issue is not about upgrading to a newer Java version. For that, see #259 (closed). (Originally #259 (closed) was part of this issue, but it has now been split into a separate issue to allow addressing them separately.)
I can confirm that Eclipse 2022-06 fixes the 'EclipseCompilerImpl creates parent directories of generated classes even for in-memory file manager' issue. I no longer see my and cifcode directories in the root of my drive after running runtime compiler tests or simulating a CIF model.
See https://www.eclipse.org/lists/cross-project-issues-dev/msg18680.html for JustJ announcement regarding JustJ and Eclipse Adoptium (successor of AdoptOpenJDK). We may expect service releases of Java 17 to become available via JustJ, rather than just a single 17.x.x version. Already for Java 11 now 11.0.12 is available as a JustJ pre-release.
Dennis Hendrikschanged the descriptionCompare with previous version
Eclipse 2021-12 is available as of yesterday. I propose not to upgrade just before our %v0.4 release but to instead do that as part of the %v0.5 release.
I'm not sure we should go to Java 17 yet. For the product we can just include Java 17. But there are other users (myself included in my day job) that use e.g. CIF as a set of plugins and thus build against CIF and would thus need to switch to Java 17 as well. Not all companies adopt Java versions as quickly. I propose to delay Java 17 adoption a bit. I'll split the issue into two issues.
Given the discussion in #276 (closed) and the fact that #76 (closed) will be fixed in 2022-03. Should we skip this release and wait for 2022-03 instead?
Let's at least hold of on this issue for now. And then let's see what comes out of the discussions as part of #276 (closed). Then we can decide based on the update policy that we then have.
It seems several fixes (#76 (closed), #199 (closed), #221 (closed)) that we want will (likely) be in 2022-03. We are on 2021-06 currently. So we then skipped two Eclipse releases. I think we can skip 2021-12. And for now it seems logical to switch to 2022-03 once it is available. But we can decide more permanently later on.
Using unsafe http transport to retrieve http://download.eclipse.org/justj/jres/11/updates/release/11.0.12/content.xml.xz, see CVE-2021-41033. Consider using https instead.
and
Using unsafe http transport to retrieve http://checkstyle.org/eclipse-cs-update-site/releases/8.41.0.202105041735/content.xml.xz, see CVE-2021-41033. Consider using https instead.
I think we can change it to https in org.eclipse.escet.
In 2022-03 I cannot display everything below of line 133 in org.eclipse.escet.setup. In notepad++ I can display that line. It is very long and contains all kinds of special characters. Not sure what causes it.
java.lang.StringIndexOutOfBoundsException: begin 32009, end 64009, length 54782 at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319) at java.base/java.lang.String.getChars(String.java:854) at org.eclipse.swt.graphics.TextLayout.breakRun(TextLayout.java:250) at org.eclipse.swt.graphics.TextLayout.splitLongRun(TextLayout.java:2915) at org.eclipse.swt.graphics.TextLayout.merge(TextLayout.java:2892) at org.eclipse.swt.graphics.TextLayout.itemize(TextLayout.java:2789) at org.eclipse.swt.graphics.TextLayout.computeRuns(TextLayout.java:270) at org.eclipse.swt.graphics.TextLayout.getLineCount(TextLayout.java:1918) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:1270) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:908) at org.eclipse.swt.custom.StyledText.getPointAtOffset(StyledText.java:5698) at org.eclipse.swt.custom.StyledText.getLocationAtOffset(StyledText.java:4529) at org.eclipse.jface.text.WhitespaceCharacterPainter.drawLineRange(WhitespaceCharacterPainter.java:248) at org.eclipse.jface.text.WhitespaceCharacterPainter.handleDrawRequest(WhitespaceCharacterPainter.java:205) at org.eclipse.jface.text.WhitespaceCharacterPainter.paintControl(WhitespaceCharacterPainter.java:181) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4243) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1063) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1087) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1072) at org.eclipse.swt.widgets.Composite.WM_PAINT(Composite.java:1536) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4803) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:340) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5023) at org.eclipse.swt.internal.win32.OS.DispatchMessage(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3630) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596) at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
Someone is looking into the issue. Assuming it will be fixed for 2022-06, what do we want to do? Upgrade now to 2022-03 and later to 2022-06 as well, or wait now, and go directly to 2022-06? Given #276 (closed), we must "[u]pgrade to a new Eclipse version at least once a year, to stay current", so we must upgrade to 2022-06 for sure then.
Note that as of 2022-06 M2 the Orbit repo has less plugins. See the announcement, which indicates:
Reminder: As of 2022-06 this is no longer a composite repo. The final CVS defined bundles are available in R20201118194144[4]. If you need these old bundles I highly recommend you add recipes to orbit[5] or change to other options like the new Maven in PDE option[6]. We don't really have a way to rebuild these old bundles therefore having your project depend on them is a risk in your project.
That message indicates a long list of things that are no longer present. We'll have to see whether that affects us or not. If it does, we may have to contribute new plugins to Orbit, which may take some time. Although, we could use the last CVS-based Orbit repo directly, to still get those plugins until we contribute them to Orbit.
As indicate, we could alternatively try to get them directly from Maven. I tried that previously, but it didn't work as we had a too old Eclipse version. Since we are here upgrading to the latest Eclipse, that should not be a problem. Also, Oomph did not yet support it, but that seems to have been addressed as well.
I tried the RC1 version. The generated target file does not contain org.apache.httpcomponents.httpclient.win, which was a problem in the 2022-03 version. So that is also solved.
However, I was not able to build, as all tests in RuntimeJavaCompilerEclipseTest fail.
java.lang.RuntimeException: Compilation failed. at org.eclipse.escet.common.app.framework.RuntimeJavaCompilerTest.compile(RuntimeJavaCompilerTest.java:363) at org.eclipse.escet.common.app.framework.RuntimeJavaCompilerTest.testInnerClassStatic(RuntimeJavaCompilerTest.java:241) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:93) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)Caused by: org.eclipse.escet.common.app.framework.javacompiler.RuntimeJavaCompilerException: Run-time Java code compilation failed (with 1 source files):with output (157): class "org.eclipse.jdt.internal.compiler.batch.ClasspathJsr199"'s signer information does not match signer information of other classes in the same packagewith diagnostics (1): line 0, column 0: ERROR: java.lang.SecurityException: class "org.eclipse.jdt.internal.compiler.batch.ClasspathJsr199"'s signer information does not match signer information of other classes in the same package at org.eclipse.escet.common.app.framework.javacompiler.RuntimeJavaCompiler.compile(RuntimeJavaCompiler.java:235) at org.eclipse.escet.common.app.framework.RuntimeJavaCompilerTest.compile(RuntimeJavaCompilerTest.java:361) ... 27 more
Since this is not the actual released version, I haven't spent much time on trying to fix this.
I tried the RC1 version. The generated target file does not contain org.apache.httpcomponents.httpclient.win, which was a problem in the 2022-03 version. So that is also solved.
class "org.eclipse.jdt.internal.compiler.batch.ClasspathJsr199"'s signer information does not match signer information of other classes in the same package
I wonder if maybe we should report this, such that it can be fixed before the release? Otherwise we maybe can't move to this release, and have to wait for the next one?
It seems the release is already on June 15, so 3 days from now. So not much time left. Maybe we're already to late? However, maybe they can still fix regression issues?
I'm willing to file an issue against JDT, but then we need to check with the latest RC first, I think.
I don't think this is the issue, as all these unsigned plugins have nothing to do with the JDT compiler. I think they are also only in the P2 configuration (for the development environment), not in the target platform (against which we resolve and compile).
What update site did you configure in Oomph, and ends up in the target platform after you've regenerated it? In the end that's what matters, as that is used during the Maven build (and the build within the development environment as well). You could even by accident have a development environment based on RC1, and a build against RC2, or so.
Ah, we use the composite update sites, that contain all milestone, release candidate build, and the final release. Thus we automatically get whatever is the latest.
I've set up a development environment myself. In the runtime it actually does work. Only the tests fail. They are now JUnit tests. If I run them as JUnit plug-in tests (moving them out of src-test to src and adding org.junit to the manifest, the tests succeed in my development environment. I think we can just turn them into JUnit plug-in tests (in a separate plugin) like we have in other places. Then I think it will work, hopefully also in the Maven/Tycho build.
The For any Java versions upgrade instruction does not include: Update Java version for executionEnvironment in org.eclipse.escet.releng.configuration/pom.xml.
Tycho does not seem to resolve Java 11.0.15, which is the one the installer uses:
[ERROR] Cannot resolve target definition:[ERROR] You requested to install 'org.eclipse.equinox.p2.iu; a.jre.org.eclipse.justj.openjdk.hotspot.jre.full [11.0.15,11.0.15]' but it could not be found
It does work if we use 11.0.12, but the installer does not have that.