MultiReleaseLaunchTests has problems on Windows

[stephan-herrmann]

We are observing MultiReleaseLaunchTests to fail with the following error in particular on Windows:

The following java versions are required by this test but can not be found: [RequiredJavaVersion[from=11, to=16], RequiredJavaVersion[from=17, to=20]]

The test uses several strategies for location necessary JRE installations, one of which is searching in /opt/tools/java/openjdk/. Obviously that path doesn't exist on windows.

For that reason I suggest we add another fallback: search within the parent directory of the java.home of the running JVM.

[SougandhS]

Looks like this is still having issue
https://download.eclipse.org/eclipse/downloads/drops4/I20260202-1800/testresults/html/org.eclipse.jdt.debug.tests_ep439I-unit-win32-x86_64-java21_win32.win32.x86_64_21.html

The following java versions are required by this test but can not be found: [RequiredJavaVersion[from=11, to=16]]

junit.framework.AssertionFailedError: The following java versions are required by this test but can not be found: [RequiredJavaVersion[from=11, to=16]]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.TestCase.assertTrue(TestCase.java:192)
at org.eclipse.jdt.debug.tests.core.MultiReleaseLaunchTests.setUp(MultiReleaseLaunchTests.java:79)
at junit.framework.TestCase.runBare(TestCase.java:140)
at org.eclipse.jdt.debug.tests.AbstractDebugTest.runBare(AbstractDebugTest.java:2916)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:130)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at org.eclipse.jdt.debug.tests.DebugSuite$1.run(DebugSuite.java:61)
at java.base/java.lang.Thread.run(Thread.java:1583)

[stephan-herrmann]

Yes, unfortunately this hasn't been fixed but look at previous error

The following java versions are required by this test but can not be found: [RequiredJavaVersion[from=11, to=16], RequiredJavaVersion[from=17, to=20]]

vs latest

The following java versions are required by this test but can not be found: [RequiredJavaVersion[from=11, to=16]]

i.e., the change helped find a JDK in range 17-20.

I guess at this point we need help from someone with access to the server like @MohananRahul @merks or @HannesWell

• does the machine running win32-x86_64-java26 tests (Y-build) have JDK 11 installed?
  • if so: what is the path to the installation? Does it share a parent directory with the JDK 26 running the build?
  • if not: could it be added?

[HannesWell]

does the machine running win32-x86_64-java26 tests (Y-build) have JDK 11 installed?\nif so: what is the path to the installation?

It's probably installed somewhere, but I recently reworked the setup of the test environments to be fully configurable from our side (i.e. the Jenkins pipeline) and to have JDKs installed on demand, e.g. from arbitrarily configurable links.

So that installation is not in use anymore.

Does it share a parent directory with the JDK 26 running the build?

Due to the dynamic configuration probably not.

if not: could it be added?

Yes, absolutely.
I think we should continue with the current 'dynamic' configuration and install the needed JDKs on demand and then make their location available through variables named like

• JAVA_11_HOME
• JAVA_17_HOME
• ...

IIRC some JDT or PDE tests could use a JDK-8 but are skipped if none is available.
Does this sound good?

If yes, I can do the corresponding adjustment, although I probably can't do it before next week.

[stephan-herrmann]

does the machine running win32-x86_64-java26 tests (Y-build) have JDK 11 installed?\nif so: what is the path to the installation?

It's probably installed somewhere, but I recently reworked the setup of the test environments to be fully configurable from our side (i.e. the Jenkins pipeline) and to have JDKs installed on demand, e.g. from arbitrarily configurable links.

So that installation is not in use anymore.

Does it share a parent directory with the JDK 26 running the build?

Due to the dynamic configuration probably not.

if not: could it be added?

Yes, absolutely. I think we should continue with the current 'dynamic' configuration and install the needed JDKs on demand and then make their location available through variables named like

• JAVA_11_HOME
• JAVA_17_HOME
• ...

@laeubi maybe you can weigh in how your test from #753 can be made to succeed in all relevant environments: locally, CI-builds, and here: production builds, where it still fails on windows.

My latest change assumed that somewhere on disk there is some folder like /org/foo/java which contains subfolders for all relevant JDK installations.

OTOH, we don't want to require all JDT developers to create various environment variables.

IIRC some JDT or PDE tests could use a JDK-8 but are skipped if none is available. Does this sound good?

Not sure what you are proposing here? Do you suggest the test in question here should simply be skipped if its requirements are not met?

[HannesWell]

My latest change assumed that somewhere on disk there is some folder like /org/foo/java which contains subfolders for all relevant JDK installations.

OTOH, we don't want to require all JDT developers to create various environment variables.

That makes sense.
But a multi-stage approach could fit for both cases:

1. Check if JAVA_XX_HOME environment variables exist and point to existing folders
2. Search for co-located JVMs with a suitable heuristic.

The second point would then only be executed if these env-variables don't exist.

IIRC some JDT or PDE tests could use a JDK-8 but are skipped if none is available. Does this sound good?

Not sure what you are proposing here? Do you suggest the test in question here should simply be skipped if its requirements are not met?

Actually I intended the opposite: Enable that test for I-builds when these other JDKs are available.

[laeubi]

@laeubi maybe you can weigh in how your test from #753 can be made to succeed in all relevant environments: locally, CI-builds, and here: production builds, where it still fails on windows.

The requirement is impossible to fulfill in general due it obviously would be insufficient to scan the whole filesystem, we do not want to automatically download JVMs and all environments can be arbitrarily be configured.

Then the test has worked for a longer time now and is already quite lenient about the actual JVM (e.g. it uses ranges for matching versions) and is using the JDT autodiscovery feature, so I'm not sure what else can be made here,

My latest change assumed that somewhere on disk there is some folder like /org/foo/java which contains subfolders for all relevant JDK installations.

I don't think it makes much sense to modify the test itself with such assumption. and instead modify the logic in DetectVMInstallationsJob what already searches for a wide range of options.

one of which is searching in /opt/tools/java/openjdk/. Obviously that path doesn't exist on windows.

This was only added specifically for the how the CI infra is setup on Jenkins. If that path is different on windows, I would propose to make it check for the osname contain "windows" and use a windows specific path.

OTOH, we don't want to require all JDT developers to create various environment variables.

I don't know if really all developers will need to run all test always ... and apart from that as mentioned the autodiscovery should fix that for them in most cases anyways. So for me it more feels like a CI setup problem than a general one.

[stephan-herrmann]

@laeubi maybe you can weigh in how your test from #753 can be made to succeed in all relevant environments: locally, CI-builds, and here: production builds, where it still fails on windows.

The requirement is impossible to fulfill in general due it obviously would be insufficient to scan the whole filesystem, we do not want to automatically download JVMs and all environments can be arbitrarily be configured.

I didn't say it should work in all theoretically possible environments, only in the revelant environments listed above.

Then the test has worked for a longer time now

Are you sure?? See, e.g., https://download.eclipse.org/eclipse/downloads/drops4/R-4.38-202512010920/testresults/html/org.eclipse.jdt.debug.tests_ep438I-unit-win32-x86_64-java21_win32.win32.x86_64_21.html

and is already quite lenient about the actual JVM (e.g. it uses ranges for matching versions) and is using the JDT autodiscovery feature, so I'm not sure what else can be made here,

My latest change assumed that somewhere on disk there is some folder like /org/foo/java which contains subfolders for all relevant JDK installations.

I don't think it makes much sense to modify the test itself with such assumption. and instead modify the logic in DetectVMInstallationsJob what already searches for a wide range of options.

I wouldn't mind if DetectVMInstallationsJob would be smarter, but with a smaller scope (fix the tests without over burdening DetectVMInstallationsJob) it might be easier to come to an agreement.

one of which is searching in /opt/tools/java/openjdk/. Obviously that path doesn't exist on windows.

This was only added specifically for the how the CI infra is setup on Jenkins. If that path is different on windows, I would propose to make it check for the osname contain "windows" and use a windows specific path.

Checking osname is good. Whether or not a specific path on windows makes sense needs to be negotiated with @HannesWell .

OTOH, we don't want to require all JDT developers to create various environment variables.

I don't know if really all developers will need to run all test always ...

Every developer working on JDT/Debug should be in the position to run all tests successfully. Always or seldomly doesn't make a difference.

and apart from that as mentioned the autodiscovery should fix that for them in most cases anyways. So for me it more feels like a CI setup problem than a general one.

Right, the CI problem is the primary issue here.

I trust that @laeubi and @HannesWell are able to negotiate a solution that clears this test off the list of constant failures. 😄

Keep in mind: the purpose of the test is to demonstrate that given a suitable set of JDK installations launching against each of them invokes the correct set of classes. How the test finds those JDK installations, is immaterial for this task, it should just be robust.

[laeubi]

I didn't say it should work in all theoretically possible environments, only in the revelant environments listed above.

So still its unclear whats "relevant". e.g if you say JDT devs should be able to run the test I assume a JDT developer is familiar with the concept of JDK installs and is able to provide whats needed here (and we just maybe need to enhance the message if its unclear).

Then we can assume that the CI is setup properly to fullfill our requirements (that always is / was we have multipe jvms installed and they are somehow at known places or env variables are defined).

So given that I don't know how much can be changed given the restrictions you mentioned that the test must run on a real JVM.

Are you sure??

At least no one ever complained as far as I know that it always fails on windows before so it must have been working some time.

I trust that @laeubi and @HannesWell are able to negotiate a solution that clears this test off the list of constant failures

I'm not sure what I can propose other than to give the hint that the Autodiscovery is used with a special additional path for the CI on Jenkins. I even opened a HelpDesk issue a while back here to ask that Jenkins would adhere more to what other CIs do:

• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6508

they mentioned some workarounds to define the env variables on there own, but given the complexity and customization of our pipelines I'm not sure one can apply it just as is.

[stephan-herrmann]

@laeubi did you see that @HannesWell offered to help? Proposed steps:

• adding the desired JDK installation to the build
• make it discoverable, e.g. by exposing its location via a dedicated environment variable

We only need the two of you to agree on the details, then each side can implement its part.

And let's please focus on the Windows side of it, which makes this different from https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6508 AFAICS.