[jsr294-modularity-eg] .spkg file format

[Alex Buckley]

Hi Bryan,

I agree that if SuperpackageFile follows the structure of ClassFile, 
then tools should parse it immediately. From my discussions, it does not 
appear that tools rely heavily on the CAFEBABE value in ClassFile, so we 
can use a new value to indicate SuperpackageFile.

The member and export lists have to be encoded in a way unknown to 
current tools whichever option is picked. Tools are familiar with 
parsing attributes and exposing them programatically, whereas decoding 
encoded field values would be new code for everyone. So it is quite 
logical to introduce attributes for members and exports. I think option 
2 will suit everyone.

I'm travelling this week but Andreas and I will comment on your proxy 
issue soon.

Alex

Bryan Atsatt wrote:
> 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
>>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg