Loosening requirements for super() invocation

[Tagir Valeev]

Hello!

As an IDE developer, I support allowing statements before this/super
invocation, without referencing `this`. This is often an annoying edge
case in many refactorings or quick-fixes. E.g.:
- If you want to introduce local variable from an argument expression
in this/super call, you cannot do this
- If you want to inline method called inside this/super call (like
inline method() in super(method(x))), you cannot do this, unless
method() is a one-liner. Even with one-liner it's complicated, as we
usually add variable declarations to assign parameters, then try to
inline these declarations, but this approach doesn't work well here,
as these temporary declarations are forbidden.
- If you have a stream API call inside this/super call (like
super(list.stream().map(...).filter(...).toList())), you cannot
desugar it to loop, as there's no place to put this loop.

On the other hand, I don't think that allowing `this` references
(e.g., field initialization) before this/super call is a good idea.
This would add more complexity to the specification and more confusion
with little advantage. Supporting super() inside try also sounds like
an overkill. Btw what about inside the synchronized {} section?

With best regards,
Tagir Valeev.

On Mon, Oct 31, 2022 at 8:18 PM Archie Cobbs <archie.cobbs at gmail.com> 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 and 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.
>
> 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. The compiler changes are here.
>
> 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