Java Platform Module System

[Alex Buckley]

On 4/27/2017 12:38 PM, Stephan Herrmann wrote:
> On 25.04.2017 19:02, Alex Buckley wrote:
>> JPMS semantics (notably, dependency resolution) are defined by the API
>> specification (not the implementation) of
>> java.lang.module.Configuration and friends. JLS references to JPMS are
>> references to this Java SE API.
>
> Got it. Since now JLS is no longer self-contained it would tremendously
> help if we could get a list of which parts of the API specification are
> expected to be considered at compile time. I understand that we need to
> apply the naming rules for automatic modules. Is there more that should
> be respected / validated / enforced at compile time?

The JLS was never self-contained as it always referenced a variety of 
java.lang and java.io types (and more recently java.lang.annotation and 
java.lang.invoke types). I have changed 7.3 to state:

"The host system must use the Java Platform Module System (as if by 
execution of the 'resolve' method of java.lang.module.Configuration) to 
determine which modules are read by M (§7.7.1). It is a compile-time 
error if the Java Platform Module System is unable to determine which 
modules are read by M."

That is, if a compiler processes a module declaration mentioning 
"requires X;", and the "as if" JPMS resolution fails because no module 
called "X" is found (whether an explicitly declared module with that 
name, or an implicitly declared i.e. automatic module with that name), 
then compilation fails too. The mapping from a JAR filename to an 
implicitly declared i.e. automatic module name is part of JPMS 
resolution. And even if a module called "X" is found, there are other 
reasons why JPMS resolution (and hence compilation) can fail, e.g. the 
module requiring X also requires Y and both X and Y export the same 
package. The JLS, as is traditional, allows a compiler to be as helpful 
or as terse as it likes w.r.t. the content of the compile-time error 
message.

> Let me add a friendly reminder, that we are still waiting for a
> specification that unambiguously tells us which module system to implement.
> For illustration:
>
> (A) Is JPMS a module system that keeps the semantics of qualified names as
> they are in Java 8 and only superimposes encapsulation boundaries?
> (i.e., each type is globally uniquely identified by its qualified name).
>
> (B) Is JPMS a module system that maintains the assumption that from the
> perspective of each module all relevant types can be distinguished using
> their qualified name?
> (i.e. admitting identical qualified names as long as no compilation of one
> module will ever encounter several candidates at once).
>
> (C) Is JPMS a module system that establishes a separate namespace for each
> module, where types with identical qualified name - but defined in
> different modules - need to be distinguished?
> (i.e., uniqueness is primarily required for module-prefixed qualified
> names).
>
> Despite some efforts I fail to find a definite answer in JLS (and Alex
> mentioned that some of this is still being discussed). Still JLS as of
> today sounds mostly like (A). To me (B) sounds like the natural choice, but I
> understood Alex as saying it *should* be (C). I don't see, however, how the
> conceptual framework of JLS could possibly support such design.

(B) and (C) are not mutually exclusive because (B) was worded from the 
perspective of each module while (C) was not.

(B) is true. Assume two modules M and N each contain the type P.C, but 
neither module exports P (or, M exports P and N doesn't, or, N exports P 
and M doesn't). Then, a third module O can require M and N. If code in 
any module refers statically to a type P.C, then JPMS resolution 
guarantees that P.C is either defined by that module or is exported to 
the module by exactly one other module which the module reads.

At run time, when 'java' is run with M+N+O on the modulepath, the system 
will stop -- M+N+O will pass resolution (i.e. a Configuration will be 
constructed) but they can't all be mapped to the application class 
loader. javac will produce a lint warning to this effect. However, M and 
N and O are by no means "bad" modules, either individually or jointly, 
as M+N+O will work if mapped to a multi-loader layer. So, (C) is true too.

The JLS, as is traditional with classes and packages, does not restrict 
the modules which can be given as input for an invocation of a compiler. 
A compiler is assumed to be able to process multiple modules at once. In 
the case of M and N, a compiler will encounter P.C in M and P.C in N, 
and is expected to distinguish them -- code in M refers to P.C in M 
while code in N refers to P.C in N. This (C)-style property is now 
expressed in 4.3.4:

"Two reference types are the same compile-time type if they are declared 
in compilation units associated with the same module (§7.3), and they 
have the same binary name (§13.1), and their type arguments, if any, are 
the same, applying this definition recursively."

> PS: I'm also having hard times to imagine, how those parts of the
> specification, that are focused on compilation units, can possibly define
> aspects like accessibility when looking at .class files, not compilation
> units - but hopefully, this is just a technicality in how the spec is
> worded, not a conceptual problem.

The JLS has never said how a compiler should process a mix of 
compilation units and .class files, yet compilers have figured it out. 
Everything in 7.3 about the host system associating compilation units 
with modules is applicable to associating class files with modules.

Alex