Module-file format (DRAFT)
Alex Buckley
Alex.Buckley at Sun.COM
Fri Jan 15 14:52:01 PST 2010
- Does "length of filename" mean a) number of bytes in the 'name' item,
or b) the number of Unicode code points in the 'name' item ?
- Filenames can include path separators, implying relative filenames.
What are they relative to, or does it not matter?
- A top-level ModuleFile structure would contain ModuleFileHeader +
ModuleInfoSection + an array of section objects + HashSection. A count
of the number of section objects is useful as a minimal well-formedness
check.
- In ModuleFileHeader, it would be super-smart to add a 'u2
meta_version' item that indicates the version scheme used for 'major'
and 'minor'. This allows corrections to the semantics of major/minor
over time.
- Is a u4 really enough for every size item?
Alex
Mark Reinhold wrote:
> Here's a first cut at a simple module-file format.
>
> Comments welcome!
>
> - Mark
>
> ----
>
> Jigsaw module-file format DRAFT
> ===============================
>
> Mark Reinhold <mr at sun.com>
> 15 January 2010
>
>
> Goals
> -----
>
> - Optimized for streamed reading, from beginning to end. Random access
> should not be required when reading a module file, though it can be
> required when writing.
>
> - Content-specific compression: Pack200+gzip/lzma for classes, bzip2 for
> native code, etc.
>
> - Independent of any specific installed-module format or target-filesystem
> capability.
>
>
> Layout
> ------
>
> A module file has the following sections, in the order listed.
>
> The first two sections are required:
>
> - Header -- Magic number, format version, sizes
> - module-info.class (never compressed, so as to be easily readable by tools)
>
> These sections are optional:
>
> - Classes (excluding module-info.class)
> - Resources
> - Native libraries
> - Native launchers
> - Configuration (i.e., properties) files
>
> The final section is required:
>
> - Secure hash of the entire file (except for this section)
>
>
> Module file header
> ------------------
>
> ModuleFileHeader {
> u4 magic; // FileConstants.MAGIC
> u2 type; // FileConstants.Type.MODULE_FILE
> u2 major; // FileConstants.ModuleFile.MAJOR_VERSION
> u2 minor; // FileConstants.ModuleFile.MINOR_VERSION
> u4 csize; // Size of entire file, compressed
> u4 usize; // Space required for uncompressed contents
> // (upper bound; need not be exact)
> }
>
> All integers are in network byte order.
>
>
> Section headers
> ---------------
>
> Each section has a header:
>
> SectionHeader {
> u2 type; // One of FileConstants.ModuleFile.SectionType
> u2 compressor; // One of FileConstants.ModuleFile.Compressor
> }
>
> Compression is only relevant to section content; it never applies to the
> headers defined here.
>
> For sections that contain only one entity (i.e., module-info, classes, hash)
> the section header is followed by a size pair, which is then followed by the
> content:
>
> SectionSize {
> u4 csize; // Size of section content, compressed
> u4 usize; // Size of section content, uncompressed
> }
>
> If a section contains named files (i.e., resources, native code, config) then
> each file within that section has a header, which is then followed by the
> content:
>
> SectionFileHeader {
> u4 csize; // Size of file, compressed
> u4 usize; // Size of file, uncompressed
> u2 nameLength; // Length of file name
> b* name; // File name, in UTF-8
> }
>
> File names may include directory separators, though they should not be used for
> native-code files.
>
> There is no mode field on files within a section. The module-installation code
> must set the local mode appropriately; e.g., it must make native-code files
> executable as appropriate.
>
> A hash section has the content:
>
> HashSection {
> u2 type; // One of FileConstants.ModuleFile.HashType
> u2 size; // Never compressed
> b* hash;
> }
>
>
> Open issues
> -----------
>
> - Signing: Should module files carry their own digital-signature information,
> as jar files do today, or should such information be provided elsewhere?
More information about the jigsaw-dev
mailing list