[jsr294-modularity-eg] .spkg file format
Alex.Buckley at Sun.COM
Tue Jul 17 19:29:24 EDT 2007
Recall that superpackage com.foo.test is declared in
com/foo/test/super-package.java and is compiled to
com/foo/test/super-package.spkg. We need to decide on the form of the
The file will need to contain:
- name of superpackage
- name of enclosing superpackage
- names of member packages, and possibly the types in those packages
- names of exported types
- annotations on superpackage
The file format should consider these requirements:
- ease of production by Java compilers
- ease of adoption by classfile parsing tools
- speed of parsing by VMs
- ability to completely express annotations
Many formats are possible, but I think we should stay fairly close to
the familiar binary ClassFile structure (JVMS 4.1). This lets us reuse
existing attributes for annotations, which would be non-trivial to
recreate in an alternative format.
Some options for formats:
1) Encode a superpackage declaration into ClassFile, with member and
export declarations transformed to (for example) fields with pre-defined
names and specially-formatted values.
2) Use the existing ClassFile structure as far as possible, redefining
and zeroing out items as necessary. Membership and export declarations
could be represented with new attributes (JVMS 4.8).
3) Design a new binary structure inspired by ClassFile. We could drop
irrelevant items like superinterfaces and fields. An example structure:
u4 magic; // 0xDECAFDAD ? :-)
u2 major_version; // 51 ?
u2 minor_version; // 0
u4 constant_pool_count; // Not u2 like ClassFile
u4 members_count; // Allow lots of members
u4 exports_count; // Allow lots of exports
attribute_info attributes[attributes_count]; // for annotations
Please let us know what you think. If you can privately consult authors
of classfile tools, please do so and summarize their comments here.
More information about the jsr294-modularity-eg