> > So both technologies can exist in the same VM this way. JPMS and OSGi > don't have to be friends in this situation. They just need to not interfere > with each other :-) > > If you are asking about how you can install JPMS modules in an OSGi > framework just like bundles, then there is no answer for that at this time > that I am aware of. >
As far as I can tell, it ought to be possible to have both OSGI manifest headers and a jigsaw module-info.class file existing in the same jar file, with the module-info.class being inert if the jar is not loaded as a JPMS module. In *some* situations it might even be possible to generate the module & bundle metadata from the same source. The reason for hedging is that the design goals for the underlying systems differ in critical aspects. 1. The JPMS model as it finally emerged is designed for use cases similar to the JDK - a complex system whose complete contents are under the control of a single entity, and which is subject only to relatively rare releases, which are typically monolithic in scope. The most important design goal seemed to use a single classloader, with visibility & access restrictions enforced without having to cross boundaries. 2. The OSGI model, as it has evolved, is designed for use cases involving complex systems whose components may be developed by multiple entities, where each component's release schedule may differ. I'm going out on a limb, but I don't expect JPMS modules gain much traction in JDK 9. Things may be different in JDK 10, if the current JPMS evolves to support more application & container level use cases. The biggest impedance mismatches are: 1. *JPMS modules do not really support versioning*. It is not possible to specify a version range when importing packages from a JPMS module. I believe that late changes were made to record the version of a module that a consumer module was compiled against, so build systems could be modified to conservatively guess at the actual requirements. However, since JPMS does not support multiple versions of the same package in the same layer, this is not scalable. 2. *OSGI bundles do not really support selective exporting of packages to a restricted set of bundles*. It is possible to achieve similar effects via Subsystems, but that is a heavyweight solution. 3. *OSGI bundles do not protected exposed classes from reflective access without the use of a security manager*. This issues can be addressed by, er, using a security manager. (Also, most of the JPMS restrictions on reflective access are turned off by default in JDK 9, but that's a runtime flag). In general, the OSGI metadata is richer than that contained in module-info.* . One possible approach might be to write a jar post-processor to generate basic module-info contents from manifest. It might also be possible to generate META-INF/services files and JPMS module service entries using DS metadata, but I'm less certain about that.
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
