Loosening requirements for super() invocation

[Brian Goetz]

This looks like some nice progress.

I would really like it if we had some warnings to detect more of the 
cases where `this` might escape construction, such as passing `this` 
explicitly to a method, invoking a non-final instance method, or 
invoking an instance method whose implementation is in a superclass.  
(Same for use of `this` in init blocks.)

I think the "try" part is likely to be off the table; too intrusive for 
too little value.

Have you looked at the spec to see what would need to be adjusted?




On 10/31/2022 3:18 PM, Archie Cobbs wrote:
> 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://urldefense.com/v3/__https://github.com/archiecobbs/jdk/blob/JDK-8193760/README-JDK-8193760.md__;!!ACWV5N9M2RV99hQ!IFOxLGBuSAtoSNYjvgWAbvbnDuMuHauJA4BIffX89H5Q_c0wG__CXaZEcL6ZG7_e_uQ6KhbytfzaMQ_YMAOcpvY$>.
>
> 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://urldefense.com/v3/__https://github.com/archiecobbs/jdk/blob/JDK-8193760/test/langtools/tools/javac/superInit/SuperInitGood.java__;!!ACWV5N9M2RV99hQ!IFOxLGBuSAtoSNYjvgWAbvbnDuMuHauJA4BIffX89H5Q_c0wG__CXaZEcL6ZG7_e_uQ6KhbytfzaMQ_YIuRHaaQ$>. 
> The compiler changes are here 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8193760__;!!ACWV5N9M2RV99hQ!IFOxLGBuSAtoSNYjvgWAbvbnDuMuHauJA4BIffX89H5Q_c0wG__CXaZEcL6ZG7_e_uQ6KhbytfzaMQ_Y-maJVCk$>.
>
> 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/20221031/dc7304d3/attachment-0001.htm>