p2 doesn't check Java execution-environment requirement upon installation

[sewe]

I have an Eclipse plug-in (build using Tycho) whose Bundle-RequiredExecutionEnvironment needs to be bumped from JavaSE-11 to (finally!) JavaSE-17. Alas, I am struggling a bit with the update's UX:

Someone running an old version of the Eclipse IDE on Java 11 (this means 2022-06 or older, as newer versions already require Java 17) can install the plug-in without any error or warning that the plug-in requires a newer Java version, only to find that the plug-in's bundles don't resolve. As this means that the plug-in's UI contributions simply vanish, this problem is really hard to diagnose, unless you know about the OSGi console, bundle states, and the diag command.

Do old versions of p2 (e.g., those shipping in the Eclipse IDE 2022-06) simply not check for a compatible Java execution environment prior to installation? Or am I doing something wrong and need to declare my plug-in's requirement somewhere else beyond the bundle's MANIFEST.MF?

[merks]

There is a check that was implemented quite some time ago (by @mickaelistria) but I don't recall the exact details off the top of my head. Of course we have the exact same problem with the IDE package when we hit a release cycle where the bundles start using a higher BREE. I'll investigate and get back to you with the details. Products do typically specify this in the eclipse.ini

-Dosgi.requiredJavaVersion=21

[merks]

This is the commit that I was thinking of:

535cf0e

This is the related Bugzilla:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=483383

This is the preference that was introduced:

That appears to be enabled by default, but that might be done by the EPP packages.

Is this present/enabled in your case?

[mickaelistria]

The check I had implemented is an extra check for the UI only, controlled by a preference. It's not deep into p2 so maybe the installation proces described here manages to dodge the check (and this would be possibly a bug).
The check works by evaluating an alternative installation request that:

• rejects all available a.jre.javase units by creating a negative requirement on them

  p2/bundles/org.eclipse.equinox.p2.ui/src/org/eclipse/equinox/internal/p2/ui/ProvUI.java

  Line 351 in d407170

  res.addExtraRequirements(Collections.singleton(MetadataFactory

• Removes possibly used a.jre.javase

  p2/bundles/org.eclipse.equinox.p2.ui/src/org/eclipse/equinox/internal/p2/ui/ProvUI.java

  Line 353 in d407170

  operation.getProvisioningPlan().getProfile().query(QueryUtil.createIUQuery("a.jre.javase"), null) //$NON-NLS-1$

• Add instead a unit that matches the currently running VM:

  p2/bundles/org.eclipse.equinox.p2.ui/src/org/eclipse/equinox/internal/p2/ui/ProvUI.java

  Line 355 in d407170

  res.add(currnetJREUnit);

There might be some bogus case to debug here; and running the the application under a debugger would help.

[sewe]

This is the preference that was introduced:

That appears to be enabled by default, but that might be done by the EPP packages.

Is this present/enabled in your case?

Yes, it is enabled by default in Eclipse 2022-06 (Eclipse IDE for Java Developers package).

And I am running under it under Java 11 (explicitly had to set -vm in my eclipse.ini, as by default 2022-06 ships with a Java 17 from JustJ):

eclipse.vm=/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java
eclipse.vmargs=-Dosgi.requiredJavaVersion=11

But Eclipse installs my plug-in without any warning and then simply fails to resolve its bundles:

  Unresolved requirement: Require-Bundle: com.teamscale.ide.eclipse.notifications
    -> Bundle-SymbolicName: com.teamscale.ide.eclipse.notifications; bundle-version="2025.9.0.202511070801"
       com.teamscale.ide.eclipse.notifications [420]
         Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=17))"

[merks]

I would have hoped it would kick in for that case. I suppose it's a bug that it doesn't. Christoph's suggestion has some merit.

[laeubi]

Just as a hint, I think you have upgrade for a purpose and you are using platform API. So the best way to prevent "silent failure" is to update the lower bounds of your dependencies to match those of when platform introduced Java 17 requirements.

[sewe]

Unfortunately, that is not a viable workaround in my case, as some of our customers are stuck with really old versions of Eclipse (as far back as Photon). Luckily, they often can (and do) upgrade their JRE independently (in particular since those really old versions didn't come with a bundled JREs yet), so we can say something "we are compatible with Eclipse Photon if running on Java 11". It just would be nice to make this statement not only in the release notes but also in the installer (as an error).

[merks]

That's really a bind then because even if we were to improve p2, the people stuck on really old things would not benefit while the people who are not on really old things actually don't have a problem. 😢

[sewe]

True, but nothing that some release notes and direct customer contact won't be able to resolve. So I'm still psyched that I finally get to enjoy Java 17 at least.

[laeubi]

Depending on how much you like to support the use-case you can do the following now with modern JDT/Tycho:

1. Create a source folder with as old Java version you like
2. Place an Activator there that opens a popup "Your are running with a too old java please use X to use this wonderful plugin", you can write to the error log of course as well
3. Then create a Multi-Release source folder (e.g. src_17) and place your code there and with an empty Activator

Then on any older java version it runs the Activator that will inform the user and execute your actual code when running on the right java version, your manifest can then declare a BREE matching to the oldest.

Of course wan would even be able to compile the old code there as well ... just as you like ;-)