Comments and questions on JSR 308 draft from January 23, 2013
mernst at cs.washington.edu
Sun Mar 31 10:47:47 PDT 2013
> 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
> Mike, please see section 2 of the PDF spec linked from
> 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.
More information about the type-annotations-spec-experts