Why not use the Manifest?

[forax at univ-mlv.fr]

Hi Paul, 

yes and no. 
you can create a package implicitly in Java so you don't need a package-info, 
but at the same time, you can use @SuppressWarnings on a package declaration (my students do that :( ) and it changes the behavior of the compiler on all the source files of the package. 

Anyway, you're right that module-info is more integrated to the language than package-info. 

regards, 
Rémi 

----- Mail original -----

> De: "Paul Benedict" <pbenedict at apache.org>
> À: "Java Platform Module System (JSR 376) Expert Group Observers"
> <jpms-spec-observers at openjdk.java.net>
> Cc: forax at univ-mlv.fr
> Envoyé: Mercredi 21 Octobre 2015 01:53:09
> Objet: Re: Why not use the Manifest?

> Regarding this point by Mark:
> > 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.

> I think listing "packages" here is a fallacy. Packages are not equal to
> classes and interfaces. You actually need binary .class files to have
> classes or interfaces -- not true for packages though. You can have packages
> without any package-info.java ever present. That file is nothing but
> meta-information and it does not affect the actual way code is built and
> executed in the package. Yet module-info.java is taking this to the "next
> level" by creating metadata that actually will affect runtime behavior.
> Based on what you specify, class loaders are affected and more.

> Cheers,
> Paul

> Cheers,
> Paul

> On Thu, Oct 15, 2015 at 1:53 AM, Peter Kriens < peter.kriens at aqute.biz >
> wrote:

> > I think our differences come from the fact that you assume that
> > module-info.java will be written by developers while I fail how to see that
> > can work realistically.
> 

> > The build system must already have metadata that contains module name and
> > version (both for the current project and the dependencies), for example
> > the
> > pom.xml in maven. You think it is realistic to expect people will write the
> > module name in two places?
> 

> > For all practical cases, will the module info not be generated by the build
> > system?
> 

> > Kind regards,
> 

> > Peter Kriens
> 

> > > On 14 okt. 2015, at 21:28, forax at univ-mlv.fr wrote:
> 
> > >
> 
> > > ----- Mail original -----
> 
> > >> De: "Peter Kriens" < peter.kriens at aqute.biz >
> 
> > >> À: "Remi Forax" < forax at univ-mlv.fr >
> 
> > >> Cc: "Mark Reinhold" < mark.reinhold at oracle.com >,
> > >> jpms-spec-experts at openjdk.java.net
> 
> > >> Envoyé: Mercredi 14 Octobre 2015 17:00:50
> 
> > >> Objet: Re: Why not use the Manifest?
> 
> > >>
> 
> > >> But packages are sealed by a manifest header, as is the signing
> > >> structure.
> > >> So
> 
> > >> the JVM must already read the manifest today?
> 
> > >>
> 
> > >> Kind regards,
> 
> > >>
> 
> > >> Peter Kriens
> 
> > >
> 
> > > Some JVM parse the manifest, but it's not part of the JVM spec.
> 
> > >
> 
> > > But where are losing ourselves in the details.
> 
> > > The compiler should check if the module-info is well formed so the error
> > > will be reported at compile time and not at runtime.
> 
> > > Now, if the compiler checks the module-info file, the textual
> > > representation should be described in the JLS and
> 
> > > binary representation described in the JVMS.
> 
> > >
> 
> > > Using a text file in that context will be weird.
> 
> > >
> 
> > > regards,
> 
> > > Rémi
> 
> > >
> 
> > >>
> 
> > >>> On 14 okt. 2015, at 15:41, 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
> 
> > >>>>
> 
> > >>>>
> 
> > >>
> 
> > >>
>