"final" ReceiverParameter?

Alex Buckley alex.buckley at oracle.com
Tue Oct 22 14:13:44 PDT 2013

I also agree with syntactically disallowing 'final' on a receiver 
parameter, for three reasons:

1. Historically, 'final' was disallowed in the 
java-annotation-design.pdf document: the FormalParameterOrReceiverDecls 
production did not allow VariableModifier terms before the receiver 
parameter (section 2.2 item 5). A recent javac allows 'final' in this 
location, which is a bug.

2. Conceptually, the receiver parameter has no effect on the rest of the 
code - it is specified as "an optional syntactic device" - so it would 
be confusing for an effect-free 'final' to appear.

3. Semantically, 'final' is a modifier for a _variable_, while 'this' is 
not a variable (it is a keyword that denotes a value) and the receiver 
parameter is not a variable declaration. So, the idea of a "final 
'this'" is unsound.

I will modify the ReceiverParameter production in the JLS draft to use 
{Annotation} rather than {VariableModifier}.


On 10/22/2013 9:05 AM, Michael Ernst wrote:
> I concur with both of these comments.  Thanks, Markus, for your careful reading!
>                      -Mike
>> Subject: "final" ReceiverParameter? (was: Public Review for JSR 308)
>> From: Markus Keller <markus_keller at ch.ibm.com>
>> To: type-annotations-spec-comments at openjdk.java.net
>> Date: Mon, 21 Oct 2013 17:32:16 +0200
>> Alex Buckley <alex.buckley at oracle.com> wrote on 2013-10-16 20:32:38:
>>> http://cr.openjdk.java.net/~abuckley/308.pdf
>> Two more nits:
>> 1.
>> ReceiverParameter:
>>    {VariableModifier} UnannType {Identifier .} this
>> VariableModifier syntactically allows annotations and "final". I don't
>> think "final" makes sense here, not even optional. {VariableModifier}
>> would better be replaced by {Annotation}. Otherwise, we'd need some spec
>> text that tells that "final" is not a legal modifier for a receiver
>> parameter.
>> 2. Typo on p.18: "that type is the type is the newly constructed object"
>>     => 2nd "is" should be "of"           ^^
>> Markus

More information about the type-annotations-spec-experts mailing list