I'm finally getting around to making that FAQ

Ethan McCue ethan at mccue.dev
Sun Mar 30 17:44:10 UTC 2025


Maybe I'm wrong, but I think the general need for "put super at the end"
came out of valhalla's design for value classes. If so, there's probably
something related on that mailing list around "why would you bother?"

Like, the rules relaxation would be in service of allowing value classes to
not be as much of a weird exception

On Sun, Mar 30, 2025, 1:34 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> OK looks like you've tracked down the important stuff already.
>
> The JEP advertises "flexibility" but in some ways the more important
> feature is safety, because it allows a subclass to prevent a superclass
> constructor from invoking an overridden method that would then see
> uninitialized subclass fields. This was a long-standing issue with Java
> constructors of course. Related is the "this-escape" warning which grew out
> of those same discussions, prior to the JEP itself, as a way to at least
> raise awareness of the problem.
>
> Another nuance is that until this JEP the JLS's application of "static
> context" to constructors was out of touch with the reality of how the
> compiler has actually worked since JDK 8. See JDK-8301649 for a description
> of that. And there turned out to be more subtlety and corner cases in the
> "early construction" context than we initially realized, once you started
> looking at things like multiple nestings of local classes, etc. Note, many
> of these issues existed before this JEP; they just required more oddball
> syntax like this:
>
> public Foo(int x) {
>     super(switch (x) {
>         default -> {
>             class Bar {{ Foo.this.hashCode(); }}  // should this be
> allowed?
>             yield x;
>         }
>     });
> }
>
> And as you noted there was some "horse trading"; the original proposal had
> two additional "flexibilities" that were not included. The first was to use
> DA/DU analysis to verify exactly one super() or this() invocation. This
> would have allowed constructors like this:
>
> public Foo(int x) {
>     if (x < 0)
>         super(-x);
>     else
>         super(x);
> }
>
> The second would have allowed super() or this() inside a try block:
>
> public Foo(Object obj) {
>     try {
>         super(obj.hashCode());
>     } catch (NullPointerException e) {
>         throw new IllegalArgumentException("illegal null value");
>     }
> }
>
> This additional flexibility was deemed unnecessary - at least for now -
> which I think was the right call to facilitate getting it done (because of
> the reduced JLS impact).
>
> -Archie
>
> On Sat, Mar 29, 2025 at 10:03 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Thanks Archie!
>>
>> To help limit your search, I went through all of Amber Dev and Amber Spec
>> Experts, from Jan 2022 up to now. I only really found a whole bunch of
>> "Sounds great to me" and "Where should we draw the line?". It may make
>> sense to turn some of those "Where's the line?" questions, and turn them
>> into FAQ answers, but nothing really popped out to me.
>>
>> That aside, I found a lot of discussion on Amber Dev, primarily Oct/Nov
>> 2022. That seems to be where this whole thing started.
>>
>> Btw, it was a very cool read to see a feature organically grow from a
>> simple discussion to an actual JEP. It's a great guideline for how to do
>> this right. Plus, more of it was out in the open than most JEP's, so easier
>> to learn how to follow along.
>>
>> And finally, here is the work-in-progress thus far, in case you want to
>> correct what I have done.
>>
>>
>> https://github.com/openjdk/amber-docs/pull/27/files#diff-126888cfc483a0bf4a51486e84145f7b07150e75c1b28d252bf01b3f493aeba8
>>
>> Thank you for your time and help!
>> David Alayachew
>>
>>
>>
>> On Sat, Mar 29, 2025 at 10:38 PM Archie Cobbs <archie.cobbs at gmail.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> There was lots of discussion on amber-dev but it may be hard to track
>>> down. I am happy to dig up some of those threads and will follow up in a
>>> few days with some links for you.
>>>
>>> Thanks a lot for putting this FAQ together! I think it will be a great
>>> resource to have.
>>>
>>> -Archie
>>>
>>> Archie L. Cobbs
>>>
>>>
>>> On Sat, Mar 29, 2025 at 7:30 PM David Alayachew <
>>> davidalayachew at gmail.com> wrote:
>>>
>>>> Question for the group -- can anyone find any question about JEP
>>>> 447/482/492 that might go into a FAQ?
>>>>
>>>> I have been going through at least one feature a week, and I am on
>>>> Flexible Constructor Bodies, and I can't find any questions people seem to
>>>> have with it. I have scoured (to the best of my ability) Reddit and Amber
>>>> Dev. I am going to go through Amber Spec Experts next, but just wanted to
>>>> see if, either I missed something in Reddit/Amber Dev, or if someone has
>>>> direct/private emails that capture some questions that are "FAQ".
>>>>
>>>> And sorry to solo you out, but adding you directly @Archie Cobbs
>>>> <archie.cobbs at gmail.com>! Since you gave birth to this feature lol.
>>>>
>>>> In the meantime, I'll add a super weak "Why do we need this feature?"
>>>> to the FAQ, because that is the grand total of all that I could find for
>>>> this featurefrom my search thus far. And tbf, I have good answers for it,
>>>> it's just not that enticing of a question, and I feel like there are more
>>>> questions I just haven't found.
>>>>
>>>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250330/a4798f36/attachment.htm>


More information about the amber-dev mailing list