Loosening requirements for super() invocation

[John Hendrikx]

I've been looking at the examples, and I find none of them compelling.  
It seems to be primarily fighting against the symptoms of another 
problem: `this` references escaping.

The `FilteredSet` example is a good example of why calling an instance 
method before an object is fully constructed is bad. In this case 
`HashSet` itself is calling a non-final method `addAll`, instead of a 
final `internalAddAll` or something similar.  Furthermore, `FilteredSet` 
is relying on this undocumented behavior, which is bad as this 
presumably can still change in a future JDK.  Furthermore, even with the 
current restrictions in place, a `FilteredSet` can be implemented fairly 
easily, so in itself that's not a good enough reason to relax the super 
calling requirements.

The `BigPositiveValue` example is quite contrived (as you said), and not 
something I'd ever need to write.  First, it perhaps feels more natural 
to check failing conditions before calling super, but as long as 
construction is prevented, the end result is the same. A smart compiler 
can re-order these I suppose.  Second, giving the constructors radically 
different behaviors when numeric input is either `long` or `float` would 
never pass review. Static factory methods that can be named ("of(long)", 
"pow2(float)") would be ideally suited to disambiguate these and avoid 
potential bugs and confusion.

I find the idea of having better warnings (or even errors) for `this` 
references escaping much more compelling.  It should flag any method 
calls that aren't private or final, with implicit or explicit this 
references.  This would highlight the mistakes made in `HashSet` 
allowing them to be fixed.

--John

------ Original Message ------
>From "Archie Cobbs" <archie.cobbs at gmail.com>
To amber-dev at openjdk.java.net
Cc "Vicente Romero" <vromero at openjdk.org>; "Brian Goetz" 
<brian.goetz at oracle.com>
Date 31/10/2022 20:18:19
Subject Re: Loosening requirements for super() invocation

>This is an old thread which I've been looking at again lately.
>
>To summarize, the idea is to relax the JLS rules about code prior to 
>super()/this() invocation to more closely match what the JVM allows, 
>which is field assignments and any code that doesn't reference 'this'. 
>Relevant issues are JDK-8194743 
><https://bugs.openjdk.org/browse/JDK-8194743> and JDK-8193760 
><https://bugs.openjdk.org/browse/JDK-8193760>.
>
>In order to make this idea less theoretical, I've prototyped all the 
>required compiler changes. There is also a write-up describing them 
><https://github.com/archiecobbs/jdk/blob/JDK-8193760/README-JDK-8193760.md>.
>
>There are a few interesting subtleties, e.g. relating to initialization 
>blocks, and there is also a sub-question, which is whether to allow 
>invoking super()/this() within a try block (this would have to be under 
>the restriction that any catch or finally clause must not return 
>normally). Currently that's not possible without a small JVM change, 
>which I also think might be worth considering to really round out this 
>new feature. See the writeup for details.
>
>To see some examples of what would be allowed, see this unit test 
><https://github.com/archiecobbs/jdk/blob/JDK-8193760/test/langtools/tools/javac/superInit/SuperInitGood.java>. 
>The compiler changes are here 
><https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8193760>.
>
>Thoughts?
>
>-Archie
>
>On Thu, Jan 17, 2019 at 8:42 AM Brian Goetz <brian.goetz at oracle.com> 
>wrote:
>>Some things have improved for this feature since we last talked; 
>>several verifier issues that this would have pushed on have been 
>>resolved.  So it’s moved from the “way too expensive for the benefit” 
>>category into the “there are lots of things we can do, is this really 
>>what we want to spend our effort and complexity budget on” category.
>>
>>My view on this is that while there’s nothing wrong with it, it’s also 
>>a pretty minor wart.  If this fell out of a bigger feature, I’d 
>>certainly not object, but I’d rather spend the effort and complexity 
>>budget on things that have broader benefit.
>>
>> > On Jan 16, 2019, at 5:48 PM, Archie Cobbs <archie.cobbs at gmail.com> 
>>wrote:
>> >
>> > I'm curious what are people's current thoughts on loosening the
>> > requirements for super() invocation in the context of Amber, e.g.:
>> >
>> >    public class MyInputStream extends FilterInputStream {
>> >        public MyInputStream(InputStream in) {
>> >            if (in == null)
>> >                throw new IllegalArgumentException("null input");
>> >            super(in);      // look ma!
>> >        }
>> >    }
>> >
>
>--
>Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221101/965bf288/attachment-0001.htm>