Module-file format (DRAFT)

[Roger Riggs]

Hi Mark,

Current development environments and runtimes are expected to support 
automated
discovery, distribution and verification. This is made possible when the 
artifacts
completely describe themselves and their dependencies.  This information 
is used
to establish and verify assumptions and invariants needed to support 
robust operation.
It is no longer acceptable to require a user to establish or fix a valid 
configuration.

The kinds of information are needed are:

    * End user identification of the module, icon, languages supported, etc.
    * Dependencies of native code - instruction set/versions,
      OS name/version,  specific drivers or other native code packages.
    * Hardware dependencies - is there a keyboard, screen size, type of
      networking, etc.
    * Ownership and rights - vendor, license term either for user or
      automated verification
    * Etc.

In the JAR format, the manifest was available as a full extensible place 
to record
additional information.  Its main drawback was having to search the JAR 
to find it
and the requirement to encode as text.

This meta information is needed for communication between the IDE,
distribution server, and runtime at least. Jigsaw itself does not need 
to define the
meta data semantics.  Incorporating an extensible placeholder into the 
distribution
format can enable a single artifact to keep the information consistent 
and available.

Roger


On 1/22/10 7:05 PM, Mark Reinhold wrote:
>> Date: Wed, 20 Jan 2010 16:14:48 -0500
>> From: roger.riggs at sun.com
>>      
>    
>> Where is the content of the config section defined?
>>      
> It's just a collection of named files.  It's meant to contain things like
> the properties files currently found in $JAVA_HOME/lib, nothing more.
>
>    
>> Does it contain information about which OS and which hardware architecture
>> the native code is appropriate for?
>>      
> No.
>
>    
>>                                      Or is that in the module-info.class?
>>      
> No.
>
>    
>> Can I have a "fat" package with multiple native code implementations for
>> different platforms?
>>      
> No, and I'm skeptical that "fat" packages are the way to go.
>
> When modules are published on a server we can use simple URL conventions
> to distinguish "pure" modules from those containing native code for a
> specific target os/arch combination.  In the long run we should probably
> record that information in the format itself, as a sanity check.
>
>    
>> If the sections are strictly in order then having the config section
>> earlier would be useful to setup how to handle the rest of the
>> sections.
>>      
> (N/A, see above)
>
>    
>> Can you remind me why multiple sections of each type are not useful/allowed.
>>      
> Simplicity.
>
> - Mark
>