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

[Archie Cobbs]

On Tue, Jun 11, 2024 at 12:11 PM Stephan Herrmann <
stephan.herrmann at berlin.de> 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.
>
> 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.
>

I'm simply agreeing that (a) we should stick with the rules in JEP 482 and
(b) how an anonymous class and the lambda equivalent are treated should be
consistent (which is what you get with (a)).


> What I took home so far is:
> * javac and ecj both accept some programs that violate JLS version 22
>

Yes - and note, it's not just about outer instances. The JLS says "static
context", which means no generic type variables, etc. See JDK-8301649
<https://bugs.openjdk.org/browse/JDK-8301649>.


> * the concept "chain of enclosing instances" can be an illusion
>    (but replacing this.this$0 with val$this$0 could pretend it's real)
>

There are really two illusions, which the compiler has to deal with
internally because happen "below" the specification, and these cause a
bunch of compiler pain/complexity:

   - An indirect outer instance is not accessed directly but must be
   accessed by "hopping" through a direct outer instance
   - The synthetic instance field that stores an outer instance cannot be
   used in an early construction context, so the constructor bytecode has to
   use the synthetic constructor parameter that provided it directly instead.

* did you say implementing JEP 482 will cause code to be rejected that is
> currently accepted?
>

No! JEP 482 should be a strict expansion of the set of valid source files.
This is true both at a specification level and a "what javac compiles"
level (these levels are different because the compiler doesn't perfectly
match the specification).


> * 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?
>

As far as I know, *modulo bugs*, the implemented behavior in javac matches
JEP 482.

The current *modulo bugs* are for example JDK-8333766
<https://bugs.openjdk.org/browse/JDK-8333766>, JDK-8333822
<https://bugs.openjdk.org/browse/JDK-8333822>, JDK-8334037
<https://bugs.openjdk.org/browse/JDK-8334037>.

I'm trying to help figure these out but so far am flummoxed. Maurizio has
made some progress though and I'm hoping he'll keep going :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240611/4f7a1b69/attachment-0001.htm>