Tim_Ellison at uk.ibm.com
Fri Feb 13 14:06:08 UTC 2015
"jpms-spec-experts" <jpms-spec-experts-bounces at openjdk.java.net> wrote on
> 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:
> This is distilled from the draft Goals & Requirements document for the
> overall modularization effort , 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
> : http://openjdk.java.net/projects/jigsaw/goals-reqs
- 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
- 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:
> 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
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
> 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
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
> 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
Is that interpretation valid. How do you see this working in practice?
> 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
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
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
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the jpms-spec-observers