RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it

[Rafael Winterhalter]

Hi,

I remember remotely that this has been a discussion several times before,
this would especially be useful if it was also applied to anonymous inner
classes. The argument against, if I recall correctly, is that adding a
field access can create unexpected behavioral change, for example by
introducing memory leaks where there has not been one before only as the
result of an inline access change. With consistent handling, at least the
outcome is consistent and errors are not first introduced after minor
changes. I could however not find the threads on it, and I do personally
agree that there is potential for improvement.

I do however think that you must retain the constructor to accept the outer
instance, no matter if it is stored in a field or not. Otherwise, a public
inner class might change its constructor and introduce a binary
incompatible change if a field access of the outer class is removed or
added and this class is recompiled independently. If the constructor only
stores the field depending on the need to use it or not, the same effect is
achieved without risking such API breakage.

Without this, API developers would need to be very careful to include a
field access also if it is no longer required, after changing a class. For
instance,

class Outer {
  class Inner { }
}

would compile to bytecode for instantiation of Inner similar to:

new Outer.Inner();

after adding a field access from outer to inner, the bytecode would change
to:

new Outer.Inner(new Outer());

That's why the desugared code should look like this I think:

class Outer {
  class Inner {
    Inner(Outer this$) { }
  }
}

where the field is only added if required.

Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210803/d2f38a6c/attachment.htm>