Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)

[Maurizio Cimadamore]

On 11/06/2024 18:11, Stephan Herrmann wrote:
> Am 11.06.24 um 17:57 schrieb Archie Cobbs:
>> On Tue, Jun 11, 2024 at 10:35 AM Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com 
>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>     My point is that we'd probably want the two examples above to 
>> align, which
>>     probably means going with the rules in JEP 482 (or some alternate 
>> rules
>>     which achieve the same effects).
>>
>> I agree.
>>
>> -Archie
>
> Can you help me fully appreciate your agreement? Somewhere in the 
> discussion I lost track which example was presented to prove which 
> point and what the consequences would be.
>
> What I took home so far is:
> * javac and ecj both accept some programs that violate JLS version 22
Yes. And, interestingly, before -source 22, ecj did not accept any of 
these problematic programs. I think that, in itself, this speaks quite a 
bit re. how common code like this really is.
> * JEP 482 has a more consistent set of rules than before
check
> * the concept "chain of enclosing instances" can be an illusion
>   (but replacing this.this$0 with val$this$0 could pretend it's real)
checl
>
> What I haven't understood:
> * did you say implementing JEP 482 will cause code to be rejected that 
> is currently accepted?
>   - which examples fall in this category?
No, I didn't say that. I believe the changes in JEP 482 correctly 
specify what the behavior should be, _under the assumption_ that we 
believe that capturing as many enclosing instances as possible in 
pre-construction context is a good thing (which it's really why I'm 
bringing this up).
> * some post spoke of tweaking JLS to model what the implemented 
> behavior is.
>    - does anyone still think this is what's happening?
>    - if so, which rule reflects implementation rather than principle?

Well, you could see the spec changes in JEP 482 as trying to provide 
some basis for what javac has been done since 1.4.

This doesn't mean the new rules are reflecting "implementation".

But the rules do seem biased towards "accepting the biggest possible set 
of classes in pre-construction context".

Now, I don't think the arguments of "we have to support this because 
code out there use this" is valid. The fact that ecj never supported 
this is just another piece of evidence that this line of thinking is flawed.

BUT, there is a more valid argument, which I brought up in a recent 
email, where I pointed out that trying to compile as many classes in 
pre-construction context has a nice effect when it comes to alignment 
with lambda expressions. A lambda expression does not introduce a _new_ 
class declaration, so it side-steps all the question about what its 
enclosing instance is. It can just use whatever enclosing instance is 
available in the context where the lambda appears. But, if you turn the 
lambda into a local class, and say (as I proposed) that the local class 
has no enclosing instance by virtue of being in a pre-construction 
context, that creates an asymmetry: the lambda expression can access 
enclosing instances that are not available in its local class counterpart.

Whether that's a big enough argument towards supporting JEP 482 in all 
its ramification I don't now (and I'd have to think more about it). But 
at least this is an argument that I can see us defend (e.g. code 
refactoring is an important use case).

Maurizio

>
> thanks,
> Stephan