Negative requirement to reject a wiring? How to force a particular Java version?

[mickaelistria]

I'm working on a plugin that use javac internal API. This API is not really an API, so it changes on every Java version.
I'd like to express that my bundle is stuck to a particular version of Java, which I know has the necessary Javac API. At the moment, just restraining to 1 particular major version of Java seems enough (we may need finer grain later, but not yet, so let's not bother with it unless it brings a simpler solution right now).
If I use Bundle-RequiredExecutionEnvironment: JavaSE-21 then Java 22 will match
If I use Require-Capability: osgi.ee;filter:=" (& (osgi.ee=JavaSE) (version=21))" then Java 22 will match because it does provide the Java 22 capability
If I use ``Require-Capability: osgi.ee;filter:=" (& (osgi.ee=JavaSE) (version=21)(version<22))" then Java 22 would still match, because its osgi.ee 21 capability will match.

Is there a way to tell Equinox "I don't want to wire against any module which provides this capability? Something like Reject-Capability: osgi.ee;filter:=" (& (osgi.ee=JavaSE) (version>21)(version<22)) ?

Or maybe it's something to reconsider more deeply in Equinox: maybe Java 22 should not provide osgi,ee 21 capability and should only provide the osgi.ee 22 one, and a BREE: JavaSE-21 which seems currently translated to Require-Capability: osgi.ee;filter:=" (& (osgi.ee=JavaSE) (version=21) shoudl instead be translated to Require-Capability: osgi.ee;filter:=" (& (osgi.ee=JavaSE) (version>=21) ?
I believe this would allow the simpler cases to keep working while allowing finer grain restrictions against particular Java versions.

[laeubi]

osgi.ee / bree are more a way to express the used class version not says anything about the java packages version so I think this is correct. If you need specific java features, you should therefore import the java packages you use.

For this particular very special case you can use a Multi-Release jar and just add a dummy implementation that throws an exception for any java version higher than the supported one, that way you can even support multiple java versions in the same bundle:

• https://github.com/eclipse-tycho/tycho/blob/main/RELEASE_NOTES.md#building-multi-release-jars

[merks]

@mickaelistria

I would test your assertion because the way I understand it, the one thing providing these capabilities, i.e., the system bundle, must satisfy all the constraints specified. So as I understand it you can specify that the system bundle must have a certain constraint version of the capability. I think you are assuming that the capabilities themselves is isolated things that can be used on their own when in fact they are bound to the thing providing them. I.e., this is about what are the valid wires to the system bundle...

[laeubi]

@merks I don't think the system bundle exports one requirement with a version list but multiple ones with individual versions, so it will at least match one of them it is not required that it matches all (what would be impossible e.g. if I require Java 11 at minimum and the framework provides also Java 8 then this would be the same situation).

[merks]

I think this works according to this test:

I.e., the system bundle just have version 16 but may not have version 17 where my actual JRE is version 17 in the launch. Of course any JRE 17 or higher will have the 17 capability and will be rejected...

[merks]

Actually testing the runtime behavior I see this failure:

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.oomph.setup.core [403]
  Unresolved requirement: Require-Bundle: org.example.test; bundle-version="1.0.0"
    -> Bundle-SymbolicName: org.example.test; bundle-version="1.0.0.qualifier"
       org.example.test [551]
         Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=16)(!(version=17)))"

	at org.eclipse.osgi.container.Module.start(Module.java:493)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2069)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:143)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2060)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2000)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1963)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1879)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:341)

So I do think this should work and does work.

[merks]

FYI, the system bundles provides these capabilities:

[mickaelistria]

So I do think this should work and does work.

OK, great thanks. I was certain it wouldn't work for the reason mentioned by @laeubi (I had some confused memories of the requirements being separated). But it's really great that it does.
Thank you very much for verifying my assertions and proving me wrong; I'm in practice happier that way ;)

[merks]

Helpful people like you have earned helpfulness in return. 🥇 And I really did want to understand this better myself too!