#LayerPrimitives

[David M. Lloyd]

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