On 07/02/2014 11:47 AM, [email protected] 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, [email protected].
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
