Loosening requirements for super() invocation

[Kevin Bourrillion]

On Mon, Oct 31, 2022 at 3:08 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> 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.)
>

Just to say: that would be awesome. Escaping thisses are really confounding
to static analysis, because few method bodies can ever be known to be
running safely past the construct-initialize gap.

On the main topic, for whatever it's worth, if more things like this became
possible I'm not 100% sure we'd allow them in our codebase anyway. The best
practice is still "don't do work in constructors": have a method get all
the field values ready so the constructor has only to store them. The
reason again is that the construct-init gap is a nasty place for code to
live in, where bugs are hard to reliably prevent. Fortunately methods
wrapping constructors often serve better as external API for several other
reasons anyway.

That doesn't constitute an argument *against* the feature.



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

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221031/68dbedc0/attachment.htm>