[records] Ancillary fields

Kevin Bourrillion kevinb at google.com
Wed Apr 18 21:59:02 UTC 2018

On Wed, Apr 18, 2018 at 1:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Ahh, you missed the `lazy` keyword on there :-) Which is good because it
> raises an issue: when you forget it, bad performance may result without
> other observable consequence. Although, it's already the case that reading
> code like the above ought to raise all kinds of alarm bells (e.g., now I
> want to go check which fields computeHashCode() might be referring to, and
> where *they're* initialized), so I *should* be looking for that `lazy`
> keyword to put my mind at ease. So maybe this is okay.
> Well, "bad" is relative; it won't be any worse than what you do today with
> eager static fields.

Yes, it's just that lazy and eager code aren't as trivially distinguishable
anymore, so... I thought I should mention it, but it's no kind of

> For instance fields, we have a choice; use extra space in the object to
> store the "already initialized" bit, or satisfy ourselves with the trick
> that String does with hashCode() -- allow redundant recomputation in the
> case where the initializer serves up the default value.

I strongly suspect there isn't going to be any generally safe way to do the

So I think the divide is not ref-vs-primitive but whether we are willing to
> take the recomputation hit when it serves up a default value.

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

More information about the amber-spec-observers mailing list