Trust final fields in records
janis at schoeck-netz.de
Tue Jun 16 09:53:25 UTC 2020
I agree that a grace period would probably cause more fuzz than it would
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
A constructor can do all sorts of things undesirable for deserialization.
One alternative might be an implicit static method parallel to the
sets all field values, but does not execute any explicit constructor(s),
Sort of a 'raw' constructor.
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
More information about the hotspot-runtime-dev