Why not use the Manifest?

[Paul Benedict]

I find the module info to be more about  visibility and dependency
management than anything else. It affects compilation but I don't even see
a reason for it to be compiled. Yes, interpreted, but no binary format
needed. It could remain as-is for runtime too. I haven't yet bought into
the assertion that extending the Java language syntax for module
information is the proper answer. Everything so far is simple structured
information that would be a great XML file or manifest, not so much Java
language.
On Oct 14, 2015 7:13 PM, <forax at univ-mlv.fr> wrote:

> Hi Paul,
>
> ------------------------------
>
> *De: *"Paul Benedict" <pbenedict at apache.org>
> *À: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Peter Kriens" <peter.kriens at aqute.biz>,
> jpms-spec-observers at openjdk.java.net
> *Envoyé: *Mercredi 14 Octobre 2015 16:02:50
> *Objet: *Re: Why not use the Manifest?
>
> Remi, but I think this is conflating two issues. The java compiler could
> be designed to consume a different kind of structured file. The module
> descriptor doesn't have to be a .java source file.
>
> Cheers,
> Paul
>
>
> It doesn't have to, but given that things like package-info is already a
> Java source file,
> why introduce a new kind of structured file when you can just re-use a
> Java source file.
>
> cheers,
> Rémi
>
>
> On Wed, Oct 14, 2015 at 8:41 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> I don't think so, it's part of the tools descriptions,
>> the manifest is described as part of the java/jar commands.
>>
>> Anyway, it's important that the module descriptor is checked at compile
>> time (by javac) and at runtime (by java),
>> thus, it has to be a part of Java the language with a syntax
>> understandable by javac.
>>
>> Rémi
>>
>> ----- Mail original -----
>> > De: "Peter Kriens" <peter.kriens at aqute.biz>
>> > À: "Mark Reinhold" <mark.reinhold at oracle.com>
>> > Cc: jpms-spec-experts at openjdk.java.net
>> > Envoyé: Lundi 12 Octobre 2015 18:51:52
>> > Objet: Re: Why not use the Manifest?
>> >
>> > Isn’t the manifest already part of the JVM specification?
>> >
>> > Kind regards,
>> >
>> >       Peter Kriens
>> >
>> > > On 5 okt. 2015, at 20:50, mark.reinhold at oracle.com wrote:
>> > >
>> > > 2015/9/28 9:49 -0700, peter.kriens at aqute.biz:
>> > >> The encoding of the module data in a binary class file remains hard
>> to
>> > >> understand and seems to go against the best practices we learned the
>> > >> hard way over the past decades. (Debugging!)
>> > >>
>> > >> Especially since the current proposal leaves the heavy lifting to
>> > >> build tooling. In the proposal, build tools cannot use the
>> > >> module-info.java since it does not contain sufficient
>> > >> information. (Versions being the most glaring omission for a build
>> > >> too.) Nor is the format extensible to contain build tool specific
>> > >> information. Ergo, the build tool will have to generate the
>> > >> module-info.class file.
>> > >>
>> > >> This make the class file makes these tools unnecessary hard and
>> slower
>> > >> because it must either use the compiler as an intermediate step or
>> use
>> > >> a library like ASM to create the unreadable version of its metadata.
>> > >>
>> > >> This is the first time in a very long time that I see a regression to
>> > >> binary files for meta data. Especially because there is already a
>> good
>> > >> place that all build tools are already using: the manifest.
>> > >
>> > > The reasons for expressing module declarations in source files and
>> > > compiling them into class files are mentioned in SotMS, but here's a
>> > > longer take on just this topic.
>> > >
>> > > The Java programming language, at present, provides for the definition
>> > > of three kinds of program components: classes, interfaces, and
>> packages.
>> > > They are defined in Java source files, and compiled into class files.
>> > > Such files govern, among other things, the mechanisms of symbolic
>> > > resolution and access control implemented by every Java compiler and
>> > > JVM.  A developer need not reason about any other type of file in
>> order
>> > > to understand the actions of these mechanisms.  A compiler or JVM need
>> > > not consume or produce any information other than that found in source
>> > > and class files in order to implement these mechanisms.
>> > >
>> > > The module system extends the mechanism of symbolic resolution with
>> the
>> > > concept of readability in order to provide reliable configuration.  It
>> > > extends the mechanism of access control, in part by relating it to
>> > > readability, in order to provide strong encapsulation.  To support
>> these
>> > > extensions, every Java compiler and JVM must be able to locate and
>> > > interpret descriptions of modules which convey, at least, each
>> module's
>> > > name, dependences, and exported packages.  Such descriptions,
>> regardless
>> > > of their form, will govern symbolic resolution and access control in
>> both
>> > > compilers and JVMs, so they will have to be specified in both the Java
>> > > Language Specification (JLS) and the Java Virtual Machine
>> Specification
>> > > (JVMS).
>> > >
>> > > Regardless of how they are described, modules are, fundamentally, a
>> new
>> > > kind of Java program component.  The present proposal therefore treats
>> > > them as such, in both the language and the JVM: Module descriptions
>> are
>> > > expressed and encoded in the same way as the other kinds of
>> information
>> > > that define program components and govern symbolic resolution and
>> access
>> > > control -- that is, as Java source and class files.
>> > >
>> > > This approach is immediately familiar to developers, who already think
>> > > about program components, symbolic resolution, and access control in
>> > > terms of the Java programming language.  It is easy to retrofit into
>> the
>> > > JLS and the JVMS, since those specifications are already centered upon
>> > > source and class files.  It is, finally, straightforward for existing
>> > > Java implementations and tool chains to support, since they need not
>> be
>> > > revised to handle an entirely new type of file.
>> > >
>> > > We could choose another format for module descriptions such as XML,
>> JSON,
>> > > YAML, or JAR-file manifests.  Such formats may be more convenient for
>> > > tool maintainers but we'd have to bake that format into the JLS and
>> the
>> > > JVMS, thereby increasing the complexity of those specifications and
>> their
>> > > implementations.  If the format depends upon external standards (XML,
>> > > JSON, YAML) then these foundational specifications, and their
>> > > implementations, would become dependent upon those standards.  If the
>> > > format proves unsuitable over time then replacing it with something
>> else
>> > > would require major revisions to these specifications, and to their
>> > > implementations.
>> > >
>> > > Source and class files are fundamental to the Java platform, to the
>> JLS
>> > > and the JVMS, and to their implementations and supporting tools.
>> Other
>> > > formats come and go; these will be with us forever.
>> > >
>> > >                                  * * *
>> > >
>> > > As to debugging, in the prototype we've already enhanced the jar tool
>> > > with an option to print the descriptor of a modular JAR file.  I
>> expect
>> > > similar support to show up in related tools such as jmod and javap,
>> and
>> > > eventually in IDEs and other tools outside the JDK.
>> > >
>> > > As to ease of tooling, most tools will only need to read module
>> > > descriptors, not write them, and the java.lang.module.ModuleDescriptor
>> > > class already provides convenient static methods for doing that.
>> Adding
>> > > similar methods to write descriptors would be straightforward, though
>> it
>> > > would complicate the API a bit.
>> > >
>> > > As to extensibility, class files are already in a precisely-specified
>> and
>> > > extensible format.  If a build tool needs to add information to a
>> module
>> > > descriptor then it can do so via non-standard class-file attributes,
>> > > using an existing popular library such as ASM.
>> > >
>> > > To make it easier for tools to manipulate module descriptors we could
>> > > consider enhancing the java.lang.module.ModuleDescriptor class, and
>> > > related tools, to read and write custom, non-standard class-file
>> > > attributes.  This might be a bit tricky depending on how the
>> attributes
>> > > are defined, but for simple property-style attributes it's likely
>> > > straightforward and would obviate the need to use ASM directly.
>> > >
>> > > - Mark
>> >
>> >
>>
>
>
>