[24] Monitor failures in tests of Y-Builds

[stephan-herrmann]

In particular this job should be closely monitored for [24] work:

• https://ci.eclipse.org/releng/job/YPBuilds/job/ep434Y-unit-cen64-gtk3-java24/

Unfortunately there's a HUGE number of failures outside JDT (mostly against pde.api.tools), but when you scroll down to the per-package statistics, it's possible to check just everything in org.eclipse.jdt.core*.

Status as of https://ci.eclipse.org/releng/job/YPBuilds/job/ep434Y-unit-cen64-gtk3-java24/7/testReport/

• zero failures in org.eclipse.jdt.{apt,compiler,core} tests

[stephan-herrmann]

HUGE number of failures outside JDT (mostly against pde.api.tools),

Is this something that happened before for previous Java versions? Perhaps api tools simply can't read class files of Java 24?

• Should PDE join the BETA_JAVA24 train for this purpose?
• Or is there a simple way to exclude those tests from the build?

[stephan-herrmann]

For monitoring only jdt.core it is easier to just look at this job:

• https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Github/job/BETA_JAVA24/

[stephan-herrmann]

HUGE number of failures outside JDT (mostly against pde.api.tools),

Is this something that happened before for previous Java versions? Perhaps api tools simply can't read class files of Java 24?

Much of this was resolved, I assume by changes in jdt.lauching.

[stephan-herrmann]

We have a drop in number of tests, see https://ci.eclipse.org/releng/job/YPBuilds/job/ep434Y-unit-cen64-gtk3-java24/14/testReport/org.eclipse.jdt.core.tests.compiler.parser/TestAll/ which, however can be explained by the removal of SelectionParserTest12.java via #3264

[stephan-herrmann]

While JDT/Core's BETA_JAVA24 build is green, Y-Build tests on Java 24 abort since 2024-12-31.

Error is:

java.lang.OutOfMemoryError: Java heap space
Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: b02e40bb-2e89-48f7-acd7-62880d509c5a
Caused: java.io.IOException: Remote call on JNLP4-connect connection from 10.40.71.136/10.40.71.136:37234 failed
	at hudson.remoting.Channel.call(Channel.java:1116)
	at hudson.FilePath.act(FilePath.java:1228)
	at hudson.FilePath.act(FilePath.java:1217)
	at PluginClassLoader for junit//hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:146)
	at PluginClassLoader for junit//hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:177)
	at PluginClassLoader for junit//hudson.tasks.junit.JUnitResultArchiver.parseAndSummarize(JUnitResultArchiver.java:282)
	at PluginClassLoader for junit//hudson.tasks.junit.pipeline.JUnitResultsStepExecution.run(JUnitResultsStepExecution.java:62)
	at PluginClassLoader for junit//hudson.tasks.junit.pipeline.JUnitResultsStepExecution.run(JUnitResultsStepExecution.java:27)
	at PluginClassLoader for workflow-step-api//org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:857)
Finished: FAILURE

@MohananRahul are you aware of this problem?

[HannesWell]

While JDT/Core's BETA_JAVA24 build is green, Y-Build tests on Java 24 abort since 2024-12-31.

Looks like your change in #3517 really fixed the test result collection as you described in eclipse-platform/eclipse.platform.releng.aggregator#2625 (comment) 🎉

[stephan-herrmann]

Indeed we have fresh test results! :)

Meanwhile the following tests in jdt.core fail (while locally and during JDT-builds they pass):

• org.eclipse.jdt.core.tests.model.Java9ElementTests.test515342b
• org.eclipse.jdt.core.tests.model.Java9ElementTests.test530024_001
• org.eclipse.jdt.core.tests.model.Java9ElementTests.testSystemLibAsJMod
• org.eclipse.jdt.core.tests.model.ModuleBuilderTests.testSystemLibAsJMod
• org.eclipse.jdt.core.tests.model.ModuleBuilderTests.testSystemLibAsJMod_2

[jarthana]

Indeed we have fresh test results! :)

Meanwhile the following tests in jdt.core fail (while locally and during JDT-builds they pass):

All of them appear to be related to modules.

[stephan-herrmann]

Indeed we have fresh test results! :)
Meanwhile the following tests in jdt.core fail (while locally and during JDT-builds they pass):

All of them appear to be related to modules.

Bingo: I can locally reproduce using temurin 24+30 JDK (but not using openjdk 24+29)

[stephan-herrmann]

@jarthana Java9ElementTests.test515342b (and possibly others) explicitly tries to read jdk/jmods/java.base.jmod, but the temurin JDK used during production builds does not have any jmods.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=515342 doesn't mention jmods, so do you by any chance remember (after more than 7 years ...) why the test was written like this?

[stephan-herrmann]

@MohananRahul @HannesWell could we switch to running tests on openjdk ea 24, rather than the temurin flavor?

[HannesWell]

@MohananRahul @HannesWell could we switch to running tests on openjdk ea 24, rather than the temurin flavor?

Yes absolutely. Anything that can be downloaded via a URL, preferably in tar.gz format can be used.

Can you provide the URL?

[jarthana]

@jarthana Java9ElementTests.test515342b (and possibly others) explicitly tries to read jdk/jmods/java.base.jmod, but the temurin JDK used during production builds does not have any jmods.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=515342 doesn't mention jmods, so do you by any chance remember (after more than 7 years ...) why the test was written like this?

This may have been some leftover from the effort of bug 490103 that tried to get rid of the bogus jrt-fs.jar that represents the JRE container. But in the end, we decided it depended too much on the implementation details of the JDK.

[stephan-herrmann]

@jarthana Java9ElementTests.test515342b (and possibly others) explicitly tries to read jdk/jmods/java.base.jmod, but the temurin JDK used during production builds does not have any jmods.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=515342 doesn't mention jmods, so do you by any chance remember (after more than 7 years ...) why the test was written like this?

This may have been some leftover from the effort of bug 490103 that tried to get rid of the bogus jrt-fs.jar that represents the JRE container. But in the end, we decided it depended too much on the implementation details of the JDK.

Trying to refresh memory of old discussions I came across https://bugs.eclipse.org/bugs/show_bug.cgi?id=490103#c65

Do you think we should remove the implementation for jmod support or only disable / remove those tests?

[stephan-herrmann]

eclipse-platform/eclipse.platform.releng.aggregator#2738 did the trick: As of https://ci.eclipse.org/releng/job/YPBuilds/job/ep435Y-unit-linux-x86_64-java24/26/testReport/ jdt.core is clean again! :)

[stephan-herrmann]

Listing sibling issues for convenience:

• JDT/UI: [24] Monitor failures in tests of Y-Builds eclipse.jdt.ui#1763 (currently clean)
• JDT/Debug: [24] Monitor failures in tests of Y-Builds eclipse.jdt.debug#553 (9 failures)