-
Notifications
You must be signed in to change notification settings - Fork 5
Wrong module descriptor in org.lwjgl #10
Comments
Basically, for future reference: We had to merge
In other words, |
The custom module descriptor needs to look like this:
|
I don't get this. The |
In OSGi, there isn't a classpath or a module path. The OSGi container wires individual packages from other modules/bundles based on What is the fallback allocator? Has it always been there? The reason I merged the two modules in the first place was because it seemed like |
To be clear: The arrangement we're using works fine for OSGi right now, it's just that I'd like the OSGi bundles to continue to work as JPMS modules and I've just discovered today that I've accidentally broken the one module above. It's possible that I could avoid exporting the |
Sorry, reading that back, I realized I explained it rather poorly. OSGi uses a peer-to-peer (non-hierarchical) classloading model at package granularity. A bundle states which packages it exports, and which packages it imports. A bundle implicitly imports all of the packages that it exports. In order for a bundle A bundle can always see classes in its own packages, whether it exports those packages or not. Given the above explanation, we can assume that We can't put in the appropriate |
Yes, it's the default system memory allocator (also accessible via
It's very likely. Applications can use
How does OSGi do optional (i.e. equivalent to Also, what about rpmalloc? The solution for jemalloc should be equally applicable to rpmalloc, it can optionally be used in much the same way (just not by default). |
Hm... Not sure why I thought it was required, then. I'll try separating the two bundles again and see what happens.
Hm, right.
The
... However this as seen as somewhat poor style, because the general opinion is that services should be used to express code that may be optional at runtime. The resolution parameter isn't capable of breaking a circular dependency either - the optional part should just be read as "do not fail resolution if this particular package isn't present".
There are multiple ways to achieve this in OSGi. OSGi treats services the same way as JPMS services; a service is just an ordinary Java class or interface and you can register (and deregister) instances of a service programatically or declaratively ("declarative services") by annotating classes that are then processed by the various OSGi tools (like Bnd). OSGi best practice is currently to avoid depending on the OSGi APIs directly unless absolutely necessary. OSGi people are pretty service-obsessed; it's a core part of the specification. There's also an optional module in the OSGi compendium specification that describes a component that makes it possible to use code that uses ServiceLoader in an OSGi container. I've not personally tried this one. The main implementation of this is Apache Aries SPI Fly. You can install it into any OSGi container. I'm told it's good, but I've not personally tried it. It is possible to write code that can work as both a JPMS and OSGi service. In my own projects, I tend to abstract over the part that looks up services. Let's say I've got a bit of code that wants to look through a set of available parser implementations, and it wants to do this whilst remaining ignorant of whether it's running on OSGi or JPMS. In this case, we model parser implementations as services. I'd first define:
Then I'd implement the registry once for JPMS:
Then I'd implement one for OSGi (using compile-time-only declarative services annotations):
Then I'd write my original class that wanted to look at parser implementations such that it required the user to pass in a value of type |
I forgot to mention that the analogues to Here are a couple of examples from a library I maintain:
The above should be read as "I provide implementations of three services:
The above should be read as "I require an OSGi container that has an implementation of at least version Both of these directives are generated automatically by Bnd. It should essentially never be necessary to write any of this metadata by hand. |
This separates the org.lwjgl.lwjgl and org.lwjgl.jemalloc modules that were joined back in the original OSGi release. Affects #10
I believe I merged Unfortunately, it does mean that you still can't override the default allocator to be Anyone needing the extended jemalloc interface can get it if they need it. |
Sure, go ahead. Just to be clear, what happens now when an OSGi application includes jemalloc? Using jemalloc directly works, but the |
Yep, that's it. |
Final thing: Manually setting |
The process used to create the modules is putting the wrong module descriptor in the
org.lwjgl.lwjgl
jar:We might need to insert a custom module descriptor.
The text was updated successfully, but these errors were encountered: