On 30.05.2017 21:42, Alex Buckley wrote:
On 5/26/2017 4:12 AM, Jochen Theodorou wrote:
On 26.05.2017 01:04, Alex Buckley wrote:
[...]
The semantics of an observed JAR without module-info.class are specified
as part of JPMS resolution, and JLS 7.3 explicitly defers to that, so I
believe it is clear how a compiler must behave when a modular
compilation unit 'requires' a module that turns out to be automatic. (Of
course a big part of the migration story is that the requirer is unaware
of whether the requiree is automatic or explicit.)
Isn't the consequence that I can write a compiler which does only allow
named modules?
You mean a compiler that understands named module and does not
understand unnamed modules?
actually I was wondering more about automatic modules and inexact in my
question.
No, per JLS 7.7.5: "An implementation of the
Java SE Platform must support at least one unnamed module." The
mandates for unnamed modules in 7.7.5 are essentially identical to the
historical mandates for unnamed packages in 7.4.2.
"""
An implementation of the Java SE Platform must support at least one
unnamed module. An implementation may support more than one unnamed
module, but is not required to do so. Which ordinary compilation units
are associated with each unnamed module is determined by the host system.
The host system may associate ordinary compilation units in a named
package with an unnamed module.
"""
OK, from this I understand there must be at least one unnamed module.
Nothing about automatic modules.
What comes after that is a bit confusing to me. Could I for example say
that only compilation units, that declare to be part of a package with
the name "unnamed" will be part of the unnamed module? I mean, I
understand that the "which" refers to the way the files are given to
javac... But it feels like the JLS allows here many other variants as well.
bye Jochen
