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