Trusted final fields Was: Updated document on data classes and sealed types

As you may know, there are two kinds of final field in Java, you have final fields and trusted final fields, the former are classical final fields the later are final fields that can no be changed by reflection thus are considered as "real" final field by JITs (see https://shipilev.net/jvm/anatom

Re: Updated document on data classes and sealed types

> On Mar 7, 2019, at 4:52 PM, Kevin Bourrillion wrote: > > On Thu, Mar 7, 2019 at 12:47 PM Brian Goetz > wrote: > > Normalization can happen on single arguments or multiple: > > record Person(String name) { > public Person { >name

Re: Updated document on data classes and sealed types

Thanks for these great comments. These cut to the heart of some uncomfortable tradeoffs. > I have two remarks about this proposal. The first is basically: why allow > overriding accessors? If a record is required to have a one-to-one > correspondence between its (private final) fields and its

Re: Updated document on data classes and sealed types

I have two remarks about this proposal. The first is basically: why allow overriding accessors? If a record is required to have a one-to-one correspondence between its (private final) fields and its public accessors, and is required to “give up [its] data freely to all requestors” what possible ove

Re: Switch expressions spec

Hi Alex, Gavin, A few comments/clarifications: 1: In section, 14.15 The break Statement A break statement transfers control out of an enclosing statement, or causes an enclosing switchexpression to produce a specified value. BreakStatement: break [~~ Identifier ~~] ; break E