Loosening requirements for super() invocation

[Brian Goetz]

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

So, what you're saying is that we can't immediately promote these to 
errors, but that doesn't mean we can't have warnings.  (We are fairly 
disciplined about zero-warnings in the JDK, using @SuppressWarnings to 
augment type checking with human judgment.)

Warnings are an important part of the safety story.  For example, 
generics are subject to heap pollution because of erasure, but we make a 
strong guarantee anyway: if the entire codebase compiles without raw or 
unchecked warnings, then the synthetic casts introduced by the compiler 
at the boundary of generic and non-generic code are guaranteed to 
succeed.  Similarly, while it is a high bar, if we can reliably warn 
about this-escape, we can make a similar guarantee for the final-field 
initialization safety guarantees, which are voided by this-escape.

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

I get where you're coming from; you have a patch that you'd like to see 
integrated, so you're trying to keep the requirements narrow. But 
realistically, this patch surely needs a JEP, because it affects the 
language spec and the user-visible programming model.  And such a JEP is 
going to be more compelling if it addresses the closely-related issue of 
this-escape.

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