Use Multi-Release Type for Caller implementation

[laeubi]

The current implementation for Java 1.8 is rather complex because of only raw string info.

With Java 9+ we can use StackWalker to perform faster and easier, to still retain compatibility with Java 1.8 we use a Multi-Release type here to use that implementation on any 9+ JVM.

See

• https://eclipse.dev/eclipse/markdown/?f=news/4.38/jdt.md#multi-release-jar-compilation-support
• https://github.com/eclipse-tycho/tycho/blob/tycho-4.0.x/RELEASE_NOTES.md#building-multi-release-jars

[github-actions]

Test Results

   771 files     771 suites   58m 9s ⏱️
 3 648 tests  3 594 ✅  54 💤 0 ❌
10 878 runs  10 715 ✅ 163 💤 0 ❌

Results for commit ef3dd53.

♻️ This comment has been updated with latest results.

[HannesWell]

Looks good and I think this is fine for RC1.
Approved from PL.

Still there are a few minor part that should be unified with the Java-1.8 implementation (but that's mainly in the old one) and they can be done later, before RC2 or in the next cycle.

I also tried to test this change with a secondary Eclipse, launch from my PDE workspace and although there is a
org.eclipse.pde.junit.runtime\bin\META-INF\versions\9\org\eclipse\pde\internal\junit\runtime\Caller.class file, when I launch a junit-5/6 test from that secondary workspace only the java-1.8 impl is loaded in the test runtime.
I assume that's not an issue with JDT but with Equinox? Or is that somehow expected?

[HannesWell]

Shouldn't this stay at 1.8 or does it have to be the highest version of all contained source folders?
I assume the general jdt.core settings (with release option enabled) ensure that the main src folder isn't compiling against Java-9?

[laeubi]

Yes the JVM is always the highest (as not more the one is supported).

The source/target controls for what byte-code version is used and the release control if the compiler checks what JVM classes can be used (I'm sure @stephan-herrmann can better explain this) so we still get what we want.

[laeubi]

I also tried to test this change with a secondary Eclipse,
when I launch a junit-5/6 test from that secondary workspace only the java-1.8 impl is loaded in the test runtime

Yes I need to improve that part, the main point is that the specification is about Multi-Release JAR (!) and not Multi-Release Folders... so PDE needs to be improved (or maybe we can even do it at equinox) as we are using some special tricks here to inject dev-entries to the bundle.

[HannesWell]

the main point is that the specification is about Multi-Release JAR (!) and not Multi-Release Folders...

Indeed!

so PDE needs to be improved (or maybe we can even do it at equinox) as we are using some special tricks here to inject dev-entries to the bundle.

I'm fine with either way, but I assume Equinox would be cover more use-cases as otherwise Mutli-Release 'JAR's wouldn't work for bundles with shape dir, would they?