Project Jigsaw: Phase Two

[David M. Lloyd]

On 07/02/2014 11:47 AM, mark.reinhold at oracle.com wrote:
[...]
> To begin this phase I've drafted a new document to collect goals and
> requirements [4].  It reflects a new emphasis on security, as motivated
> by recent experience [5], it takes into account lessons learned from the
> prototype, and it's written at a broader and more abstract level than the
> previous document [2] so as not to over-constrain the solution space.
> This document will be one of the starting points of the upcoming Java
> Platform Module System JSR.
>
> Please send comments and suggestions on the new goals and requirements
> document [4] to this list, jigsaw-dev at openjdk.java.net.

Great document!  Overall this set of requirements is almost a perfect 
match with the requirements we derived for our own module system, which 
makes me feel that it is hopeful that (a) this project has found the 
right course and (b) we also have found the right course. :-)

I also agree with all of the non-requirements, with a few small caveats 
given below.

Firstly, in many places the document refers to versions of modules, 
including specifying that the module system cannot support more than one 
version of a given module.  But I believe this is somewhat misleading. 
If you think about what this really means, you have to answer the 
question: What does it mean to be a different version of a module?  Or, 
at what point do two versions of one module really conceptually become 
two separate modules?

To give an example: in our own module system, I had derived almost the 
exact same requirement, which led me to implement a "slots" mechanism 
(name inspired by the equivalent Gentoo concept).  This mechanism was 
simply an addendum to the module's name which would allow us to have, 
for example, log4j 1.x and 2.x coexisting in the same system.  However, 
experience has shown that this mechanism was not actually necessary, and 
in fact just gets abused in ways which complicate the user experience 
unnecessarily.  In retrospect a better solution would have been to 
simply have separately identified modules - in this example, there would 
be one for log4j 1.x and one for 2.x ("org.apache.log4j.1x" vs 
"org.apache.log4j.2x" perhaps), maybe with a general alias 
("org.apache.log4j") to default to one of the two.

My intent with this example isn't to start talking about implementation 
though - it's just to use a real-world example to illustrate the idea 
that "multiple versions" is a sort of human concept that doesn't really 
have an equivalent that can be mapped concisely to specification - 
something that didn't really click for me right away, retrospective 
obviousness notwithstanding.  The specification as given here does seem 
to match my experience, if you read between the lines a little (and 
deduce that a module must be identified uniquely within a configuration 
(if not globally), and that the spec-defined module version can not be a 
direct part of that identification), but I think (if not here than in 
the final specification) it will be worth having a non-normative section 
that discusses the idea versus the technical reality of multiple version 
"support", and that not supporting multiple versions as a first-order 
concept doesn't really mean you *can't have* multiple versions, per se; 
it just means that the module version constraint mechanism cannot be 
used in this way.  This will at the least have a big impact on community 
perception, as the naive user might be somewhat affronted by what they 
view as a key feature not being directly provided (even if it is 
technically still possible - perhaps even easy - to accomplish in 
practice, though perhaps in a slightly less obvious way).

Secondly, I have a minor concern about this statement:

     "Enforced version constraints — The process of configuring a set of 
modules must, in all phases, satisfy every version constraint of every 
module except for constraints that are overridden, in which case the 
overriding constraint must be satisfied."

I note that the definition of phases was even more well-hidden compared 
to the previous incarnation of the requirements doc, but it can be 
deduced from the "Upgradeable modules" item to be the set of compile 
time, build time, and run time.

My question, however, relates to run time.  I don't think one has to get 
too far into speculating about implementation to deduce that the only 
form that this constraint can take (and still be a constraint) is 
throwing an exception of some sort when a non-satisfying module is 
loaded.  My gut feeling is that once you get to run time, it might be 
more damaging to enforce this constraint than to let it slide (though 
maybe with a warning of some kind, if possible).  This was one of a 
couple small conceptual issues that has prevented me (thus far) from 
implementing a similar version metadata system for JBoss Modules (the 
other main issue being the necessity to design a proper version syntax 
which is strictly defined with a clear total order).

As a final comment, I am very glad to see the important topic of dynamic 
configurations being added to the requirements document; I think leaving 
this out would have been a very unfortunate error.

> Jigsaw as a whole will bring enormous changes to the JDK; it would be
> unwise to wait until it's completely finished before merging any of it.
> Our intent, therefore, is to proceed in large steps, each of which will
> have a corresponding JEP.  The first three JEPs, which I'll also post
> here for review, will propose a specific modular structure for the JDK,
> reorganize the JDK source code (but not binaries) along those lines,
> and then later modularize the binary images.
>
> A fourth JEP will introduce the module system itself, which will be
> aligned with the module-system JSR.  It may seem odd that the module
> system JEP comes last, but the earlier JEPs need make only minimal
> assumptions about its capabilities, hence work on them can proceed
> in parallel with work on the module-system JEP and JSR.

This seems like a very reasonable approach.

-- 
- DML