Tim Ward

> I don't see these changes as "minimally invasive". What prevents us from creating an nd4j-osgi module like the nd4j-uberjar module that doesn't require any changes to the other modules?...

> If we need to add a dependency on OSGi like that, we'll need to make sure it doesn't break anything anywhere, on Android and Spark among things... Is this...

> @timothyjward @saudet with java 17 LTS forcing module-info I added a semi related PR: #9626 > > I think I've at least solved part of the problem for modularization....

> adjust Bndtools to set for each compiled java version the appropriate release flag and generate a manifest for each of those For proper multi-release support we do need to...

> I'm not familiar with Apache Felix, but I assume that the URLs returned by Apache Felix use schemas that are native to the Java Platform, like file, jar or...

>I think that's the key-point of the problem. Extraction of directories does not work with Equinox-OSGi. If this is the goal then realistically JavaCPP will need some OSGi aware code...

> We can avoid OSGi or framework-specific code in JavaCPP if we use some service loader mechanism: adding a jar providing the service for the framework actually used to the...

> At least in Equinox the resource-URL's host is always the same for the same bundle. Do you know if this is the case for other OSGi implementations as well?...

> @timothyjward: Furthermore, is there a deeper meaning why you suggested `BundleWiring.listResources()` over `findEntries()`? You have mentioned both. The two methods do different things. `findEntries()` Is a simple way to...

> @timothyjward Is OSGi incompatible with JDK 17? I’m not aware of anything at a spec level, although some of the Java changes have caused issues for older implementations. It...