Selectively Shifting and Constraining Computation

[forax at univ-mlv.fr]

----- Original Message -----
> From: "David Lloyd" <david.lloyd at redhat.com>
> To: "leyden-dev" <leyden-dev at openjdk.org>
> Cc: "Remi Forax" <forax at univ-mlv.fr>
> Sent: Tuesday, October 25, 2022 4:07:09 PM
> Subject: Re: Selectively Shifting and Constraining Computation

Hi David,

> On Tue, Oct 25, 2022 at 1:56 AM <forax at univ-mlv.fr> wrote:
>> I've just read it, i like it, it's far better than the previous semantics and
>> using the same lock as <clinit> will allow IDEs to provide nice refactoring
>> without having to think too much.
> 
> Just out of curiosity, why might the behavior of the initialization
> lock make a difference for IDE refactoring?

Because it's under a lock, so you can not have a double initialization, so the IDE do not have to prove that there is no side effect before doing a refactoring that introduces a lazy constant.

This does not mean that the lock of the <clinit> and the lock used by the initialization of the lazy constant has to be the same, having a transient lock for the lazy initialization mey be enough. As you said, in the lazy holder pattern, the lock of <clinit> of the class is not used but the lock of the <clinit> of the holder class is used instead.

> --
> - DML • he/him


Rémi