<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <blockquote type="cite" cite="mid:CANSoFxvfMBQrdVH9CPszy2in7zdpSb6a+RjCNmNbw7Bxr2w4Fw@mail.gmail.com">
      <div dir="ltr">
        <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>
    </blockquote>
    <br>
    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.)  <br>
    <br>
    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.  <br>
    <br>
    <blockquote type="cite" cite="mid:CANSoFxvfMBQrdVH9CPszy2in7zdpSb6a+RjCNmNbw7Bxr2w4Fw@mail.gmail.com">
      <div dir="ltr">
        <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>
    </blockquote>
    <br>
    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.  <br>
    <br>
    <br>
  </body>
</html>