[jsr294-modularity-eg] JSR 294 expert group draft

[Alex Buckley]

Can you expand on the complications for protected inner classes? The 
common case for access to a protected member is within the same package, 
so superpackages are moot. And since protected inner classes cannot be 
exported (since they are not public), access from subclasses in a 
different superpackage is not possible.

As for 'hide', it is perfectly reasonable but fundamentally an 
optimization, so I have not spec'd it out in this first draft.

Alex

Eugene Vigdorchik (JetBrains) wrote:
> Would it make sense to prohibit inner classes as members of superpackages?
> Otherwise I see some complications with determinining accessibility of
> protected inner classes declared to be members of some superpackage.
> 
> Also I recall we agreed on usfulness of "hide" declaration in superpackage
> file, but the current proposal does not seem to include it. Did you come
> with some further negative arguments?
> 
> Eugene.
> 
> ----- Original Message ----- 
> From: "Andreas Sterbenz" <Andreas.Sterbenz at Sun.COM>
> To: "JSR 294 Expert Group" <jsr294-modularity-eg at cs.oswego.edu>
> Sent: Monday, October 22, 2007 8:11 PM
> Subject: Re: [jsr294-modularity-eg] JSR 294 expert group draft
> 
> 
>> [My earlier mail seems to have been lost, resending...]
>>
>> Experts,
>>
>> reminder to send us your comments about the draft spec by next Monday
>> October 29. After this expert group review, we should proceed to JCP Early
>> Draft Review so that we can gather feedback from the larger community.
>>
>> Andreas.
>>
>> Andreas Sterbenz wrote:
>>> Experts,
>>>
>>> based on our earlier discussions Alex and I have prepared a draft
>>> specification for Superpackages. It consists of updates to the Java
>>> Language Specification, the Java Virtual Machine Specification, and the
>>> reflection API.
>>>
>>> The specification reflects our past discussions in the EG, except in a
> few
>>> cases where we are suggesting changes based on our experience in the
>>> prototype implementation. For example, we changed the proposed name of
> the
>>> compiled superpackage file from super-package.spkg to
> super-package.class.
>>> That should avoid some tool compatibility issues and makes more sense
>>> given our later decision about the file format. We have also allowed a
>>> Java source file (compilation unit) to optionally identify which
>>> superpackage its types are in. There are some minor updates to the
>>> reflective API: the addition of SuperpackageFormatError and the method
>>> Superpackage.forName().
>>>
>>> You can find the documents on the EG page,
>>> http://jcp.org/en/eg/view?id=294 . We believe these drafts can serve as
>>> the basis for the JCP Early Draft Review.
>>>
>>> We would appreciate if you could send us your comments by Monday,
> October 29.
>>> Alex and Andreas.
>>> _______________________________________________
>>> 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