On 03/17/2017 11:12 AM, Stephen Colebourne wrote:
I note the discussions on various threads about JPMS primitives.
My first expectation is that OSGI and JBoss modules can run in Java 9
in classpath mode.
I believe this to be true today.
Of course.
My second expectation is that there are sufficient primitive
operations within JPMS to allow a _new_ module system (not OSGI or
JBoss Modules) to be built that permits some but not all of the
features seen in OSGI and JBoss Modules. Thes should include:
- dynamic loading/reloading of modules
- lifecycle callbacks
- multiple versions of a class loaded at the same time
- handling of clashing packages
- some form handling for module cycles
It is clear to me that JPMS does contain an API with some flexibility
here, but it is hard to judge whether my second expectation is met.
This is because the discussion is ledf by OSGI and JBoss Modules
migration concerns, rather than by consideration of what a new module
system would need. Perhaps these concerns are the same, perhaps not. I
would like to see a discussion from the EG about what blocks a
theoretical new extended module system built on top of JPMS.
In the green field, all things are possible.
You could create a variety of module systems that behave in a variety of
ways and yet still adhere to the current JPMS restrictions. If you're
willing to discard, rewrite, or retool all existing software, and change
best practices (even if the current practices are not particularly
harmful or problematic, or even useful), and derive your acceptable use
cases from the implementation restrictions (instead of the other way
around), you can conform to anything and fit in any situation.
But, accepting the proposals for this and other issues makes that green
field better for everyone, and increases that variety and decreases the
number of use cases which would otherwise be unjustly left to obsolescence.
Specifically, I note Thomas Watson's concern over non-lazy class
loader construction as being a concern [1] (point 2) for module
systems.
My third expectation is that it should be possible for bytecode/class
generation tools to generate code inside a module, including in a
package that is not known by the module graph.
A lot can be accomplished through copious amounts of bytecode injection.
But I have a hard time accepting any argument to the effect that this
is an acceptable programming interface for legitimate use cases, common
or not. Particularly when the remedy is trivial!
I note that Proxy appears to have a special case for "dynamic
modules", and am concerned that this may over-emphasise Proxy compared
to other similar tools that are not part of the JDK.
Indeed the requirement for these unusual constructs is a huge design red
flag, yet is generally dismissed on the basis that only special citizens
need access to it: a self-justifying argument with an ideological basis.
Note that while I understand the desire for OSGI and JBoss Modules to
fit into JPMS and get the benefits, I do not consider that necessary
to complete the JSR - it is more important to close out Java 9 and
move on.
Is it though? I argue that this importance is a hazardous illusion, and
furthermore has been and will continue to be used as a tool to undermine
the community process. Ten years from now, will anyone care that Java 9
was delayed another 6 months, or even a year, in order to get a few
things right? I strongly doubt it. Will they care that the community
process was shunned in favor of expedience? This seems more likely to me.
These existing systems work today, and provide benefits
today, something that won't change. That they won't get the enhanced
security benefits of JPMS modules is a secondary concern IMO.
It is perhaps secondary to the very large number of vendors and users
with a substantial investment based on these systems and, much more
importantly, the development practices they represent.
The thing that concerns me with this line of reasoning is that all of
these arguments could be used to justify anything at all. The spec lead
could just run down the clock or strong-arm the EG into nearly anything.
To contrive a humorous example, banning the use of the letter "M" from
Java could be justified this way. At what point do we start arguing in
terms of engineering standards - especially when the remedies are often
quite simple and even trivial?
--
- DML
