RFR: JDK-8236598: javac rejects record component with 'final' modifier

[Brian Goetz]

This not only goes against how constructor parameters work in every 
other class, but also against the intended use for normalization:

     record Sign(int signum) {
         Sign {
             if (signum < -1)
                 signum = -1;
             else if (signum > 1)
                 signum = 1;
         }
     }

Normalization could is most natural when it mutates the arguments, and 
then lets them be committed as a batch.  If these were final, then you'd 
have to do more (and different) gymnastics to normalize state.

On 1/6/2020 9:51 PM, Tagir Valeev wrote:
> Btw how about finality of compact constructor parameters? I assume 
> that if I declare the records component final and declare a compact 
> constructor, its formal parameters become final as well. Or not? If we 
> disable 'final' on records components, this means that compact 
> constructor formal parameters are never final?
>
> Also, current spec draft says:
>
> It can be seen that the production for /RecordComponent/ is identical 
> in content to the production for /FormalParameter/ (8.4.1 
> <https://docs.oracle.com/javase/specs/jls/se13/html/jls-8.html#jls-8.4.1>).
>
> The following productions from 8.4.1 
> <https://docs.oracle.com/javase/specs/jls/se13/html/jls-8.html#jls-8.4.1>, 
> 8.3 
> <https://docs.oracle.com/javase/specs/jls/se13/html/jls-8.html#jls-8.3> and 
> 4.3 
> <https://docs.oracle.com/javase/specs/jls/se13/html/jls-4.html#jls-4.3> are 
> shown here for convenience:
>
>
> If you disable 'final', this part is no longer true.
>
> With best regards,
> Tagir Valeev.
>
> вт, 7 янв. 2020 г., 9:08 Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>>:
>
>     My preference is to allow no modifiers on components at this
>     time.  Since there are none that are actually useful, none seems
>     like the right number.
>
>     Sent from my iPad
>
>     > On Jan 6, 2020, at 3:44 PM, Vicente Romero
>     <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>     >
>     >
>     >
>     >> On 1/2/20 3:17 PM, Remi Forax wrote:
>     >> ----- Mail original -----
>     >>> De: "Paul Sandoz" <paul.sandoz at oracle.com
>     <mailto:paul.sandoz at oracle.com>>
>     >>> À: "Vicente Romero" <vicente.romero at oracle.com
>     <mailto:vicente.romero at oracle.com>>
>     >>> Cc: "compiler-dev" <compiler-dev at openjdk.java.net
>     <mailto:compiler-dev at openjdk.java.net>>
>     >>> Envoyé: Jeudi 2 Janvier 2020 20:46:31
>     >>> Objet: Re: RFR: JDK-8236598: javac rejects record component
>     with 'final' modifier
>     >>> If you allow redundant declaration of “final” would the same
>     reasoning apply to
>     >>> “private”?
>     >>>
>     >>> I notice the spec does not specify an optionally private
>     modifier but does
>     >>> declare that the associated implicit field is private.
>     >>>
>     >>> It feels inconsistent. Did you consider the opposite direction
>     and change the
>     >>> spec?
>     >>>
>     >>> Paul.
>     >> Hi Paul,
>     >> the keywords apply on the record components, not on the
>     generated fields.
>     >> Given a record component is always accessible if the class
>     itself is accessible, "private" makes no sense in that case.
>     >>
>     >> And about allowing final or not ?
>     >
>     > I guess we should discuss tomorrow about this, allowing final or
>     not, given that it is a redundant declaration that could bring
>     some confusion it could make sense to do not allow it
>     >
>     >> I don't know.
>     >>
>     >> Rémi
>     >
>     > Vicente
>     >
>     >>
>     >>>> On Jan 2, 2020, at 10:41 AM, Vicente Romero
>     <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>     >>>>
>     >>>> Hi,
>     >>>>
>     >>>> Please review a simple fix to a bug in the records code.
>     Basically the spec
>     >>>> allows record components to redundantly declare the `final`
>     modifier. The
>     >>>> current implementation is not allowing this. This patch is
>     fixing this issue.
>     >>>>
>     >>>> Thanks,
>     >>>> Vicente
>     >>>>
>     >>>> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/
>     >>>> https://bugs.openjdk.java.net/browse/JDK-8236598
>     >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200107/e4a9a538/attachment.htm>