Draft Spec for Flexible Constructor Bodies (JEP 513)

[forax at univ-mlv.fr]

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Stephan Herrmann" <stephan.herrmann at berlin.de>, "amber-spec-experts" <amber-spec-experts at openjdk.org>
> Sent: Tuesday, April 22, 2025 11:15:59 PM
> Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513)

> On 22 Apr 2025, at 13:59, Remi Forax wrote:
> 
>> if you take a look to a code, the same code with strict field and without strict
>> fields do not offer the same publication guarantee.
>>
>>>
>>> Where should I be looking for that property of strictly initialized fields you
>>> are referring to?
>>
>> Let's take an example,
>>
>> class Foo {
>>   int x;
>>
>>   Foo(int x) {
>>     this.x = x;
>>     super();
>>   }
>> }
>>
>> // thread 1
>> global = new Foo(3);
>>
>> // thread 2
>> var foo = global;
>> if (foo != null) {
>>   System.out.println(foo.x);
>> }
>>
>> the question is what are the values that can be printed, with flexible
>> constructor bodies, it's 0 or 3, with strict fields, it's only 3.
>>
>> So you have no way to understand the behavior of the code just by looking at it.
> 
> That’s fine, but any change in behavior would be due to strict
> fields, as a feature. The behavioral difference you point out
> (0 vs. 3) is in the noise, since either outcome is valid in
> the JMM, under current rules (or with no strict fields present).

This is fine from the VM POV because the VM sees the strictness of the fields, this is not fine from the language POV because you have no way to see if a field is strict or not.

> 
> Note that SF (strict fields) add more determinism. That is not
> a flaw in layers of the language added previously, including
> FCB (flexible constructor bodies).  The new layer (SF) will be
> a improvement over something that was already good.

True, but because being strict or not is not reflected in the language,
you have no way to know if you are under the FCB or the SF semantics.

> 
> Overall, I don’t see any reason we can’t add this in two layers,
> FCB first, and then SF.  And I see plenty of reasons to do this.
> The main reason to split the work is the fact that SF requires
> deep cuts to the VM, while FCB requires no VM changes at all.

The reason is that i want to know if a code is correct or not just by looking at it,
that's a big reason why we can write concurrency algorithms in Java, because it does not have to have fear of a compilation option.

But because FCB and SF has no language difference, if SF is not introduced at the same time as FCB, it means that i can not know if a Java code has a publication problem or not.

Same example, slightly modified, lets say the field can store a reference,

lass Foo {
  String s;
  
  Foo(String s) {
   this.s = s;
   super();
  }
}

var foo = global;
if (foo != null) {
  System.out.println(foo.s.length());
}

Does this code can produce a NPE or not ?

The answer is: if FCB and SF are not released at the same time, it depends.
I would like to avoid that even if it means that FCB is delayed by several releases,
for me, being able to reason on a Java code is more important than delivering a feature earlier *.

> 
> — John
> 

Rémi

* obviously, the other parts of FCB, i.e not the field initialization before the call to super() can be delivered before the field initialization part.