Why not use the Manifest?

[David M. Lloyd]

On 10/05/2015 01:50 PM, 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!)
>> [...]
>> 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.
> [...]
> 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.

As I've described before (I think?), I believe this is a very thin 
thread to hang a fundamental design principle from.  There are lots of 
other approaches that developers would just as immediately understand, 
and MANIFEST.MF is just one of those.

> [...]
> 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.

I don't believe this is true at all, but I'll outline that in detail in 
another email.

> [...]
> 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.

This, I agree with.

> 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.

See next email for more on this.
-- 
- DML