[jsr294-modularity-eg] .spkg file format

[Bryan Atsatt]

Speaking as a member of a company that uses many forms of classfile 
parsing/generation tools (third-party and internal), my first 
inclination is to vote for an unmodified classfile format, based on 
static tools alone.

However, it just occurred to me we may need a standard mechanism to 
modify the contents of a Superpackage instance, *at runtime*, and this 
might influence the decision; we may want to start another thread for 
this, but...

Consider the case of a proxy class generated for interface 
com.acme.Dynamite.

Assuming 294 introduces a classfile change such that each class declares 
its enclosing superpackage, it will be easy to copy that declaration to 
com.acme.DynamiteProxy. But will that addition be reflected by 
Superpackage.getMemberTypes()? My assumption so far is that you are 
considering this list to be entirely static, so the answer would be "no".

We could probably live with that wart, but what if DynamiteProxy needs 
to be *exported*? So long as Dynamite itself is exported, I assume that 
any client which knows only that type will link correctly to an instance 
of DynamiteProxy.

However, the code that generates and instantiates DynamiteProxy will 
almost certainly be in a different superpackage. Do we force such code 
to use reflection/setAccessible() to invoke the default ctor or any 
other methods?

What about types that are generated and serialized? Do ObjectInputStream 
implementations also need to use setAccessible()?

Or should we consider a way to add (and only add) to the Superpackage 
member/exported type lists? If so, then perhaps we should also consider 
enabling the direct construction of Superpackage instances as well.

// Bryan

Alex Buckley wrote:
> Hello,
> 
> 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 
> .spkg file.
> 
> 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:
> 
> SuperpackageFile {
>    u4 magic;          // 0xDECAFDAD ? :-)
>    u2 major_version;  // 51 ?
>    u2 minor_version;  // 0
>    u4 constant_pool_count;  // Not u2 like ClassFile
>    cp_info constant_pool[constant_pool_count-1];
>    u2 this_superpackage;
>    u2 enclosing_superpackage;
>    u4 members_count;  // Allow lots of members
>    member_info members[members_count];
>    u4 exports_count;  // Allow lots of exports
>    export_info exports[exports_count];
>    u4 attributes_count;
>    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.
> 
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>