RFR: JDK-8236598: javac rejects record component with 'final' modifier
Brian Goetz
brian.goetz at oracle.com
Tue Jan 7 15:40:50 UTC 2020
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>
More information about the compiler-dev
mailing list