Loosening requirements for super() invocation

[Archie Cobbs]

Thanks for the various comments.

I agree the topic of "this" escaping is definitely an interesting one.
Although there is a lot of code out there that currently relies on it
(e.g., HashSet and AbstractCollection), perhaps someday we could realize
this in a backward-compatible way by adding a notion of a "safe
constructor" which would be limited to following more strict rules that
disallowed "this" escapes.

Perhaps you could declare your constructor (and/or initialized fields) to
be "safe" with an annotation, e.g.:

    @SafeConstruction
    public MyClass(int x) {
        this.x = x;         // ok
        this.someMethod();  // error here!
    }

However I'd also like to keep this discussion organized with an important
observation...

The topic of "this" escape is completely orthogonal to this change. None of
the code that would be allowed before super() or this() could allow "this"
to escape, because you're not allowed to reference "this" in any way except
for assigning values to fields. The only thing you can do is what might be
called "static housekeeping".

So this change does not make the problem of "this" escape any worse than it
already is. That means the two problems are really separate and can be
addressed separately and independently.

So I agree that Java has issues with "this" escape, and there are some
interesting ways we could address it, but I also don't see that as a reason
to prevent people from being able to do "static housekeeping" prior to
their this() or super() invocation.

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

There is one other reason to consider the JVM change, which is that
currently it's not possible for bytecode rewriting tools (e.g., aspectj) to
fully instrument constructors. The StackOverlow link talks about this use
case.

Another minor factor is that the class file format wouldn't actually need
to change, only how it's verified.

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

I've not gotten that far yet but would be happy to help/participate with
some guidance.

Thanks,
-Archie

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

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

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221101/1ec5ff20/attachment.htm>