Jigsaw and other module systems

David M. Lloyd david.lloyd at redhat.com
Fri Mar 4 22:31:51 UTC 2016

I've raised several issues but the thrust of them really boils down to 
the ability to retrofit existing module systems on to Jigsaw.  OSGi is 
certainly one of these, and of course our own module system into which 
we're reasonably invested is another.

Ultimately our needs can, I think, be met by either solving (somehow) 
the aforementioned issues, or failing that, rather by eliminating any 
disadvantage afforded to non-Jigsaw-loaded code by providing alternative 
hooks (for example, allowing class loaders to assign a name and version 
to the "unnamed" module would allow non-Jigsaw code to have stack traces 
which take advantage of the new information, or perhaps by allowing 
ClassLoaders to define their own kinds of Module that perhaps obey 
different rules or constraints than the JDK-supplied ones).

In this current situation, it is looking pretty grim for our users, who 
may want to take some sort of advantage of JDK-supplied modularity while 
still retaining compatibility with the existing module system as well as 
the extra capabilities that our existing module system has.

So just be aware that I am not intending to be inflexible about the 
issues I've raised as long as we can meet our needs some other way.  I 
am willing to engage in any discussion about these issues (in this or 
other media), also including contributing code, as this is one of my top 
priority items at the moment.  My main intention is to not leave our 
users "high and dry".

More information about the jpms-spec-experts mailing list