[type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013

[Alex Buckley]

Moving things along while Joe is away...

On 3/28/2013 9:22 PM, Michael Ernst wrote:
>> "The optional receiver parameter has no effect on execution ― it only
>> serves as a place to write annotations
>> on the receiver. The compiler generates the same bytecodes, and reflection
>> returns the same results regarding
>> number of method formal parameters, whether or not the optional receiver
>> parameter is present."
>>
>> In Java SE 8, we are also adding support for more reflective information
>> about method and constructor parameters, including modifiers as to whether
>> or not they are "synthetic" vs "mandated". The explicit "receiver"
>> parameter declarations may alter how the corresponding
>> java.lang.reflect.Parameter objects should behave in some situations. In
>> any case, the specification should be updated to be explicit about any
>> interaction or non-interaction here.
> 
> Can you point me at the specification?  (I don't see a reference to this in
> lambda, so it must be separate.)

An explicit receiver parameter isn't persisted as a formal parameter.
That's why JSR 308 prohibits a PARAMETER annotation from being applied
to it. It essentially disappears during compilation. The only trace is
that its TYPE_USE annotations persist in a *TypeAnnotations attribute in
method_info. Core reflection (j.l.r.Parameter) therefore knows nothing
about it.

Mike, please see section 2 of the PDF spec linked from
http://mail.openjdk.java.net/mailman/listinfo/enhanced-metadata-spec-discuss,
particularly the new JLS 13.1 section. An explicit receiver parameter is
definitely declared explicitly in source code, so there is no need to
mark it. (You might ask, how would it be marked? For that, see the new
JVMS 4.7.22 section, and note carefully how ACC_SYNTHETIC and
ACC_MANDATED bind to JLS 13.1.)

>> Section 3
>>
>> "The VM does not have to validate all the constraints in Section 3.3, such
>> as that offsets point to the right type of
>> instruction. The VM does not do format checking (JVMS 4.8) on attributes
>> used solely for reflection."
>>
>> The JVMS has a rich terminology in terms of what checks happen (or not)
>> where and when in the linking and loading process. This description above
>> should be tied more directly to the JVMS concepts.
> 
> Can you give specific, constructive suggestions for the terminology?  You
> can probably do that quickly and easily.  Thanks!

For this and other text which says "nothing changes" (e.g. "No changes
are made to the StackMapTable ...") it is best just to take the text
out. I plan in JVMS8 to call out attributes which are read solely by the
core reflection API (it's a growing list), since they need to be
excepted from format checking, but there is nothing surprising about the
*TypeAnnotations attribute so the less said, the better.

Alex