conditional dependency between bundles

[gireeshpunathil]

is there a notion of conditional dependency between bundles? (say for example if we are in platform A and architecture B then bundle P requires bundle Q, or else there is no such dependency exist.)

[laeubi]

is there a notion of conditional dependency between bundles

No as it usually do not is very useful, you should better describe the problem instead of the suspected solution, then one can much better help here.

e.g. platform has platform specific fragments (what can of course have different dependencies) or features can pull in bundles depending on architecture and so on but it all depends on the usecase what is sufficient here.

[gireeshpunathil]

yes - available in some, and not in all. we see the problem in zOS.

[gireeshpunathil]

@laeubi - so you mean to say: the inclusion of this dependency could have originally been a win32 specific fragment, rather than an unconditional dependency that affects all the platforms?

[laeubi]

yes - available in some, and not in all. we see the problem in zOS.

Its a bit unfortunate this only popup 5 years later and as far as I know zOS is not "officially supported" (aka we have no test infrastructure for it). So if thats important for you I would recommend ot get in contact with IDE-WG and as a first step make a zOS aviable as a test infrastructure.

If that's done and we can verify patches I see several options:

1. adding zOS support to jna that would be bring the most benefits here, as I know jna is used on other places as well
2. Using import-package instead of require bundle, you then might deploy a surrogate bundle that provides the packages
3. Making the win32 part optional by creating a win32 fragment
4. waiting for next Java Upgrade and then using FFMI instead ....

[HannesWell]

IMO option four is the way to go, although it will only be possible in about one year.

[HannesWell]

And regarding option two, you also provide a mock-jna bundle with the same name and vision (in the meantime until the FFM-api is used).

[mickaelistria]

You'd better ask this on the Equinox forum.

[gireeshpunathil]

thanks @mickaelistria - I asked it here looking at the involved bundles and thinking that folks in this repo may better know about the background, implications and remediations.

[merks]

A requirement can specify a filter. Filters often specify the os,arch,ws for which it applies. This is widely used. Eg when a feature includes fragments.

[laeubi]

A requirement can specify a filter. Filters often specify the os,arch,ws for which it applies. This is widely used. Eg when a feature includes fragments.

Please don't mix install time (P2) with runtime (OSGi) ... You can't "filter" requirements of a bundle as it would make no sense, if something is missing the bundle is not resolved. That's why I said it would be possible to split the code in two bundles (one generic and one that is only installed for win32).

[merks]

It’s easy to mix things up when reading on a phone. 😜

For the specific example maybe it could be optional greedy.

[nburnwal09]

@laeubi
we followed option 3 in your suggestion [here] by:

1. creating a fragment,
2. making it windows-wpecific,
3. defining a bundle to host the fragment,
4. routing dependency to con.sun.ja to the host bundle

and bundles successfully resolved at the launch time.
however, at runtime, we got this exception:

at org.eclipse.osgi.container.Module.start(Module.java:495) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2111) at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:146) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2102) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2042) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:2004) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1916) 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)

when debugged, we found that eclipse is still trying to load the plugin com.sun.jna, as it is referred in bundles.info file.
so looks like irrespective of what we do with the bundle dependencies, as long as the plugin is referenced from the bundles.info, it will be attempted to be loaded, and that will fail in platforms like zOS.

any suggestions to resolve this or work it around?

[laeubi]

@nburnwal09 I'm not completely sure what you did, but option (3) would actually split out the win32 part of the bundle out in a fragment (where the host is org.eclipse.urischeme) then resulting in bundle:

• org.eclipse.urischeme -> no jna dependency at all
• org.eclipse.urischeme.win32 -> contain jna dependency and jna code

your description reads like you did something else and try it on an existing Eclipse Release (what will not work).

[nburnwal09]

@laeubi

We did split out the urischeme(windows part only) into a new fragment

org.eclipse.urischeme.win32 -> contains windows specific jna code with Fragment-host as org.eclipse.urischeme
org.eclipse.urischeme -> removed all jna dependency.

Even if the unresolved dependency of urischeme is resolved, we are still getting the same below error :

Unresolved requirement: Require-Capability: **osgi.native**; native.paths.8:List<String>="com/sun/jna/sunos-x86-64/libjnidispatch.so"; native.paths.17:List<String>="com/sun/jna/linux-x86-64/libjnidispatch.so"; native.paths.7:List<String>="com/sun/jna/sunos-x86/libjnidispatch.so"; native.paths.16:List<String>="com/sun/jna/linux-x86/libjnidispatch.so"; native.paths.19:List<String>="com/sun/jna/linux-arm/libjnidispatch.so"; native.paths.9:List<String>="com/sun/jna/sunos-sparc/libjnidispatch.so"; native.paths.18:List<String>="com/sun/jna/linux-arm/libjnidispatch.so"; native.paths.13:List<String>="com/sun/jna/linux-ppc/libjnidispatch.so"; native.paths.35:List<String>="com/sun/jna/openbsd-x86-64/libjnidispatch.so";

coming from

at org.eclipse.osgi.container.**Module.start**(Module.java:495) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2111) at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:146) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2102) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2042) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:2004) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1916) 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)

Here, getting errors from bundles of other operating systems like sunos, linux, aix, etc. as listed in [bundles.info]
It is coming from Module.java start method(during compile time before child eclipse is getting launched).
....
In short, whatever we try, ending up with this error.
Any further suggestions/pointers to resolve this?

[laeubi]

We did split out the urischeme(windows part only) into a new fragment

Would you mind providing a PR for platform about this change? It would make things probably more clear and others can benefit from it.

Here, getting errors from bundles of other operating systems like sunos, linux, aix, etc. as listed in [bundles.info]

You should not include incompatible fragments into your product, also make sure your new win32 fragment has a proper platform filter so it is not considered by P2.

[merks]

@nburnwal09

Why is the focus purely on org.eclipse.urischeme? Don't these other two places also cause/have the same problem?

Is that maybe the cause of problem you are seeing?

[laeubi]

@merks yes I mentioned it before that JNA is used on other places as well... but I also don't know what is actually used here it might be a custom product that is only using a subset of bundles.

At least the security.win32 shows an example where the windows specific part is already split up.

[merks]

That's a good point. Answers have not been forthcoming, but additional questions keep coming.

I can only suggest yet again to try making the imports optional and to ensure that nothing blows up when the classes are not loadable.

External to the bundle, only these are used:

[nburnwal09]

@laeubi
We have tried making the com.sun.jna as Imported packages and made it optional across all the bundles.
org.eclipse.urischeme, org.eclipse.core.filesystem, org.eclipse.core.resources and org.eclipse.core.net

That, yet again resolving the unresolved dependency for these bundles.
But ended up getting the same above error
Unresolved requirement: Require-Capability: **osgi.native**; native.paths

[laeubi]

But ended up getting the same above error
Unresolved requirement: Require-Capability: osgi.native; native.paths

Its a bit hard to tell from some fragmented messages whats going on, but optional does not mean it is not considered. So the resolver will still (if you installed the JNA) try to match this optional import. It might be that you then get an error but things just work. I would first try to delete the JNA bundle manually from the install and start with -clean then you will see if there are any mandatory options.

[nburnwal09]

@merks @laeubi

We are considering all the bundles
org.eclipse.urischeme, org.eclipse.core.filesystem, org.eclipse.core.resources and org.eclipse.core.net

But we will raise PR for org.eclipse.urischeme first with splitting out win32 part as fragment with proper filter.
Based on the review comments on this, we can make similar changes for other 3 bundles

[merks]

@nburnwal09

I would strongly suggest not going down this path. I will also strongly reiterate the point that you are trying to solve a problem we do not have on the supported platforms. Moreover you are trying to do so in a way that complicates the common base in such a way that it will make it more challenging in the future to move to ffi which is the long term plan.

In addition, as @laeubi suggests, your error looks like one that you'd get if you deployed the non-functional jna bundles. You should be testing without deploying those at all and then, if you've made all the requirements optional such that OSGi not not create the wires, you would see class not found errors not unresolved requirements as you show above. You can carry out such tests in the development environment with a self-hosted launch.

So please don't start to create PRs for restructuring the plugin structure of the common code base because I really don't want to see such a restructuring take place.

[akurtakov]

I second that. PRs that complicate the already way too complicated system for no benefit to the wide public are not welcome. One should keep such changes if they really need it downstream.

[merks]

I setup (Oomph) a new SDK environment, made all the JNA dependencies optional and try to launch without JNA. it fails validation like this:

So I have remove the win variants of those too:

Then we see the the class loader problems such as this:

If I comment out the offending line, the workspace starts, but has this failure when shutting down:

!MESSAGE Problems occurred while trying to save the state of the workbench.
!SUBENTRY 1 org.eclipse.ui.ide 4 1 2025-05-01 11:58:36.220
!MESSAGE Internal Error
!STACK 0
java.lang.NoClassDefFoundError: com/sun/jna/Pointer
	at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.setUsingNative(LocalFileNativesManager.java:70)
	at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.reset(LocalFileNativesManager.java:52)
	at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.<clinit>(LocalFileNativesManager.java:45)
	at org.eclipse.core.internal.filesystem.local.LocalFile.fetchInfo(LocalFile.java:228)
	at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:231)
	at org.eclipse.core.internal.localstore.BlobStore.<init>(BlobStore.java:47)
	at org.eclipse.core.internal.localstore.HistoryStore2.<init>(HistoryStore2.java:104)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.getHistoryStore(FileSystemResourceManager.java:556)
	at org.eclipse.core.internal.resources.SaveManager.save(SaveManager.java:1253)
	at org.eclipse.core.internal.resources.Workspace.save(Workspace.java:2498)
	at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.lambda$1(IDEWorkbenchAdvisor.java:555)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:123)
Caused by: java.lang.ClassNotFoundException: com.sun.jna.Pointer cannot be found by org.eclipse.core.filesystem_1.11.100.qualifier
	at org.eclipse.osgi.internal.loader.BundleLoader.generateException(BundleLoader.java:567)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(BundleLoader.java:562)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:438)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:195)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 12 more

But we could guard that too:

So with two parts of the code that could be guarded for zos, without much complication, we can start a workbench without JNA and without exceptions in the error log:

And finally, when I go to the link handler preferences I get this exception which also appears could be easily guarded.

So I don't think a major restructuring is needed at all and I hope not to see such an effort.