Module-system requirements

[Tim Ellison]

"jpms-spec-experts" <jpms-spec-experts-bounces at openjdk.java.net> wrote on 
11/02/2015 18:38:31:

> From: mark.reinhold at oracle.com
> To: jpms-spec-experts at openjdk.java.net, 
> Date: 11/02/2015 18:38
> Subject: Module-system requirements
> Sent by: "jpms-spec-experts" 
<jpms-spec-experts-bounces at openjdk.java.net>
> 
> I've posted a first draft of a requirements document, here:
> 
>   http://openjdk.java.net/projects/jigsaw/spec/reqs/01
> 
> This is distilled from the draft Goals & Requirements document for the
> overall modularization effort [1], omitting items that are beyond the
> scope of the module system itself and rewording others as necessary.
> 
> As noted in the introduction, the intent of this document is to serve
> as a set of guideposts for this EG.  The specification we produce will,
> ultimately, satisfy all of these requirements.  After we finalize this
> document it will certainly be possible to revise it, but the bar for
> doing so will be relatively high.
> 
> This is the first draft, and I'm sure you'll all have many comments and
> suggestions.  I'd like to finalize the requirements by the end of this
> month (February 2015), so fire away!
> 
> - Mark
> 
> 
> [1]: http://openjdk.java.net/projects/jigsaw/goals-reqs
> 


Overall comments:

 - I have quoted sections below in providing feedback.  Hopefully that 
works well enough for you.  You may want to consider sharing the 
markdown/odf document if you want comments and questions in the full 
context.

- The requirements doc is a mixture of specification and implementation 
requirements.  For example, while I agree with the objectives of the 
linking and packaging sections, they could be more succinctly written for 
their requirements on the module system itself.

 - It would be useful to have a section on Security.  While there are 
aspects throughout other sections of the requirements, such as 
encapsulation and referential integrity, there may be other considerations 
where module boundaries can be used to enhance security, e.g. only 
allowing privilege escalation within a module scope, modules declaring all 
exported APIs fail when passed a tainted string, etc.  I'm not proposing 
scope-creep but rather ensuring folks have had the chance to think about 
it and easy opportunities are not missed to make Java 9 even more secure.

 - I wrote my comments before reading other people's.  Apologies to David, 
who did a better job of explaining the 'Exporting things' issues.


Detailed comments follow:


Fundamentals

 > Encapsulation — The access-control mechanisms of the Java language and
 > virtual machine must prevent code from accessing classes and interfaces
 > in packages that are not exported by their containing modules, or in
 > packages whose containing modules are not required by the module
 > containing the code. These mechanisms must be operative even when a
 > security manager is not present.

The document explicitly calls out classes and interfaces here as targets 
for encapsulation.  Given a module can also contain native code, static 
resource files, and user-editable configuration files, are these being 
explicitly excluded?  It would be valuable for the module system to also 
prevent access to libraries and resources that are not exported by their 
containing modules.

I appreciate this requires extending the Exports to include non-package 
resources, but the alternative is that native code and resources that are 
specific to a module's implementation would be accessible to other modules 
(if the default were to export resources), or that modules cannot access 
resources managed by other modules (if the default were to not export 
resources).


 > Non-interference — The Java compiler, virtual machine, and run-time
 > system must ensure that modules that contain packages of the same
 > name do not interfere with each other.

Can you explain "interfere"?  Is this referring to ambiguous class and 
linkage error type problems, or something else here?


 > Compatible Java Platform modularization — It must be possible to
 > divide an existing Java Platform, e.g., Java SE or Java EE, into a
 > set of modules such that existing libraries and applications can run
 > without change, so long as they use only standard platform APIs.

It is the last nine words of this that I have concerns about.  With that 
caveat I think there is a serious risk that Java 9 will be incapable of 
running a large body of existing, valuable Java code.  There is a longer 
discussion to be had about the support for 'legacy' Java code, but just as 
the document provides for 'gradual migration of applications' under 
Development, I believe there is value in a promiscuous mode for the 
modular platform or specific code source in being able to run existing 
libraries and applications without change.


 > Upgradeable modules — If a Java SE module exports an endorsed
 > standard or standalone technology then, given a particular
 > implementation of the platform, it must be possible to use a
 > binary-compatible version of that module from a later release of
 > that implementation.

This is the only use of the term 'Java SE module'.  What is a Java SE 
module?
Am I correct in assuming this is describing _runtime_ upgradeable modules, 
as clearly modules can be selected at build, link time in any case?
Why the distinction from other modules that may be upgradeable?  For 
example, if I choose to issue a patched version of my java.base that is 
binary compatible with a particular implementation of the platform, then I 
would like to be able to upgrade that at runtime (see Referential 
Integrity below).


 > Referential integrity — Given a specific set of modules comprising
 > an implementation of the Java SE Platform, it must be possible to
 > ensure that each module can only be configured to reference other
 > modules in the same set, with the exception of upgradeable modules.

(I'm choosing to interpret 'can only be configured to reference' as 'can 
be configured only to reference')

If I am interpreting this correctly it means that it must be possible, but 
not strictly required, that there is no ad hoc runtime replacement of 
modules in an SE image.  However, the set of permitted modules can be 
arbitrarily defined to make runtime replacement possible.

For example, the VM can identify through naming, code signing, directory 
location, or whatever, 'modules comprising an implementation of the Java 
SE Platform' and refuse to load their dependencies if they are not in the 
definition of that Platform set.  However, the 'defined set' is all 
modules with a given name prefix, or signature, or directory location, etc 
so I /can/ upgrade any modules comprising an implementation of the Java SE 
Platform by providing a new binary compatible module that falls within 
that set.

Is that interpretation valid.  How do you see this working in practice?


Development

 > Multi-mode artifacts — The existing JAR-file format must be enhanced
 > so that a module that does not contain native code can be delivered
 > in a single artifact that can be used either on the class path or as
 > a module.

Why the restriction on JAR files that contain native code?  Of course 
plain old JAR files would not be able to take advantage of the native code 
unless the application enabled this.  For example, OSGi allows for native 
code to be delivered via application JAR files.  Consider changing to 
"...so that a module that does not depend upon native code can be 
delivered..."


Dynamic Configuration

I am reading this section while making a clear distinction in my mind 
between the Referential Integrity of the Java SE Platform modules, and the 
more open nature of the modular application.

If this distinction is correct, then I feel we do need a clear 
'Fundamentals' definition of a Platform Module.  The module system manages 
the Java Platform modules differently to the modules of a modular Java 
application.

Although described as Basic dynamic configuration, this section does 
appear to open the door for runtime module dependency resolution.  This 
dynamic configuration is carefully avoided for the Java SE Platform.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU