ModuleClass

[Jonathan Gibbons]

Point noted about the incorrect use of CONSTANT_Utf8 instead of  
CONSTANT_Class.
I'll check that out.  Also, if I recall correctly, that item is  
followed by an array of Utf8 strings
representing an open ended set of flags/modifiers, similar to that  
used for the requires
entry. If nothing else, you might need to skip over them if there is  
any info to follow.

-- Jon


On Mar 2, 2009, at 9:26 PM, Mark Reinhold wrote:

>> Date: Mon, 02 Mar 2009 12:21:09 -0800
>> From: jonathan.gibbons at sun.com
>
>> I'm not seeing any issues with the ModuleClass attribute.    See
>> highlighted text below, or else just search through this message for
>> [cC]lass.
>
> You're right.  The "ModuleClass" attribute is making it into  
> the .class
> file, but the ModuleInfoReader code is looking for a "ModuleMain"
> attribute.
>
> Fixing this in ModuleInfoReader isn't quite enough, though; it seems  
> that
> the ModuleClass attribute's single parameter is a utf8 string rather  
> than
> the binary name of a class, so in the end the following diff does the
> trick:
>
> @@ -114,7 +114,7 @@
>     private static final String MODULE_PROVIDES = "ModuleProvides";
>     private static final String MODULE_REQUIRES = "ModuleRequires";
>     private static final String MODULE_PERMITS = "ModulePermits";
> -    private static final String MODULE_MAIN = "ModuleMain";
> +    private static final String MODULE_MAIN = "ModuleClass";
>
>     private void readAttributes() throws IOException {
>         int count = in.readUnsignedShort();
> @@ -173,7 +173,7 @@
>
>     private void readModuleMain() throws IOException {
>         int index = in.readUnsignedShort();
> -        mainClass = cpool.getClassName(index);
> +       mainClass = cpool.getUtf8(index);
>     }
>
>     private static class ModuleInfoImpl
>
> I suspect we really want ModuleClass to name a class rather than just
> convey a plain utf8 string, so I'm loathe to commit the above patch
> except possibly as a temporary measure.
>
> Alex?
>
> - Mark