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

[Michael Ernst]

> Subject: Re: Comments and questions on JSR 308 draft from January 23, 2013
> From: Alex Buckley <alex.buckley at oracle.com>
> To: type-annotations-spec-experts <type-annotations-spec-experts at openjdk.java.net>
> Date: Fri, 29 Mar 2013 14:47:58 -0700
>
> 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.

I've added a sentence of explanation along these lines, which should
address Joe's desire for clarification, and will prevent confusion in the
future.

> 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.

This is very helpful, thanks.

The new JLS 13.1 (from enhanced-metadata) uses "marked" without defining
it.  The current JLS 13.1 uses "marked as synthetic".  It would be helpful
to me if the new 13.1 was more explicit, and/or defined the term, and/or
gave a cross-reference from the word "marked" to where its definition
appears.  (JVMS 4.7.22 does not use the terminology "marked".)

> >> 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.

This is an easy change to make!  I've done so, in all the places I saw this
kind of wording.  Let me know if I missed any.

Thanks again.

		    -Mike