Trust final fields in records

[Janis Schöck]

I agree that a grace period would probably cause more fuzz than it would 
help.

But an alternative to the all-args constructor might still be needed to 
set final fields,
since serialization APIs usually need to avoid them to stay clear of 
side effects.
A constructor can do all sorts of things undesirable for deserialization.
One alternative might be an implicit static method parallel to the 
constructor that
sets all field values, but does not execute any explicit constructor(s), 
if present.
Sort of a 'raw' constructor.

- Janis

Am 15.06.2020 um 21:33 schrieb John Rose:
> On Jun 15, 2020, at 2:37 AM, Andrew Haley <aph at redhat.com> wrote:
>> On 12/06/2020 17:56, Brian Goetz wrote:
>>
>>> If we make this change when records exit preview, this will catch
>>> maintainers of these frameworks unaware — things will just start
>>> breaking when their clients use records.  But if we give them a
>>> grace period (e.g., lock it down in 17), we need to ensure that
>>> they’ll use that time effectively,
>> Has this ever happened? What seems to have happened instead is that
>> people complain bitterly about "access will be disabled in the next
>> release" warning messages, do nothing, then complain even louder when
>> access really gets disabled. Maybe I'm gitting jaundiced...
> Under the assumption that *some* people will move on this
> only when forced to move, a grace period buys nothing for
> *those* people.  It’s not like we are changing an existing
> behavior; since records are new, the grace period does not
> apply to people who have built records in good faith and
> need time to adjust.  In fact, if we give a grace period *now*
> for the slow-footed “make me change” people, we might
> well have to give *another* grace period to the more reasonable
> people that adopted records in the preview.
>
> I say, tighten the clamps now, when it hurts only a few
> people.  No grace period today.
>
> — John
>