<div dir="ltr"><div>Thanks for the various comments.</div><div><br></div><div>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., <span style="font-family:monospace">HashSet</span> and <span style="font-family:monospace">AbstractCollection</span>), 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.</div><div><br></div><div>Perhaps you could declare your constructor (and/or initialized fields) to be "safe" with an annotation, e.g.:<br></div><div><br></div><div><span style="font-family:monospace"> <a class="gmail_plusreply" id="plusReplyChip-1">@SafeConstruction</a></span></div><div><span style="font-family:monospace"><a class="gmail_plusreply" id="plusReplyChip-1"> public MyClass(int x) {</a></span></div><div><span style="font-family:monospace"><a class="gmail_plusreply" id="plusReplyChip-1"> this.x = x; // ok<br></a></span></div><div><span style="font-family:monospace"><a class="gmail_plusreply" id="plusReplyChip-1"> this.someMethod(); // error here!</a></span></div><div><span style="font-family:monospace"><a class="gmail_plusreply" id="plusReplyChip-1"> }<br></a></span></div><div><a class="gmail_plusreply" id="plusReplyChip-1"><br></a></div><div>However I'd also like to keep this discussion organized with an important observation...</div><div><br></div><div>The topic of "this" escape is completely orthogonal to this change. None of the code that would be allowed before <span style="font-family:monospace">super()</span> or <span style="font-family:monospace">this()</span> 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".<br></div><div><br></div><div>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.</div><div><br></div><div>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 <span style="font-family:monospace">this()</span> or <span style="font-family:monospace">super()</span> invocation.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> I think the "try" part is likely to be off the table; too intrusive for too little value.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Another minor factor is that the class file format wouldn't actually need to change, only how it's verified.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Have you looked at the spec to see what would need to be adjusted?<br></div></blockquote><div><br></div><div>I've not gotten that far yet but would be happy to help/participate with some guidance.<br></div><div><br></div><div>Thanks,<br></div><div>-Archie<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022 at 5:08 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<font size="4"><font face="monospace">This looks like some nice
progress. <br>
<br>
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.) <br>
<br>
I think the "try" part is likely to be off the table; too
intrusive for too little value. <br>
<br>
Have you looked at the spec to see what would need to be
adjusted? <br>
</font></font><br>
<br>
<br>
<br>
<div>On 10/31/2022 3:18 PM, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>This is an old thread which I've been looking at again
lately.</div>
<div><br>
</div>
<div>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
<a href="https://bugs.openjdk.org/browse/JDK-8194743" target="_blank">JDK-8194743</a> and
<a href="https://bugs.openjdk.org/browse/JDK-8193760" target="_blank">JDK-8193760</a>.<br>
</div>
<div><br>
</div>
<div>In order to make this idea less theoretical, I've
prototyped all the required compiler changes. There is also
a <a href="https://urldefense.com/v3/__https://github.com/archiecobbs/jdk/blob/JDK-8193760/README-JDK-8193760.md__;!!ACWV5N9M2RV99hQ!IFOxLGBuSAtoSNYjvgWAbvbnDuMuHauJA4BIffX89H5Q_c0wG__CXaZEcL6ZG7_e_uQ6KhbytfzaMQ_YMAOcpvY$" target="_blank">write-up describing
them</a>.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>To see some examples of what would be allowed, see <a href="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$" target="_blank">this unit test</a>.
The compiler changes are <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8193760__;!!ACWV5N9M2RV99hQ!IFOxLGBuSAtoSNYjvgWAbvbnDuMuHauJA4BIffX89H5Q_c0wG__CXaZEcL6ZG7_e_uQ6KhbytfzaMQ_Y-maJVCk$" target="_blank">here</a>.</div>
<br>
<div>Thoughts?<br>
</div>
<div><br>
</div>
<div>-Archie<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 17, 2019 at 8:42
AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. <br>
<br>
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.<br>
<br>
> On Jan 16, 2019, at 5:48 PM, Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>>
wrote:<br>
> <br>
> I'm curious what are people's current thoughts on
loosening the<br>
> requirements for super() invocation in the context of
Amber, e.g.:<br>
> <br>
> public class MyInputStream extends FilterInputStream
{<br>
> public MyInputStream(InputStream in) {<br>
> if (in == null)<br>
> throw new IllegalArgumentException("null
input");<br>
> super(in); // look ma!<br>
> }<br>
> }<br>
><br clear="all">
</blockquote>
</div>
<br>
-- <br>
<div dir="ltr">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div>