Module-file format (DRAFT)

Mark Reinhold mr at sun.com
Wed Jan 27 14:51:32 PST 2010


> Date: Sat, 23 Jan 2010 07:07:45 -0500
> From: roger.riggs at sun.com

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

Completely agree.

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

Yep.

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

Much (though not all) of the above information can be expressed as
annotations in a module's module-info file.  I suspect the rest can be
provided as part of the packaging process, but we'd have to work through
the use cases.

- Mark



More information about the jigsaw-dev mailing list