Another possible semantics change is the object lifetime. The code
might rely on prolonged lifetime of the surrounding object if there
are soft/weak/phantom references. E.g., the outer object might be
registered via Cleaner, and the change may cause freeing the resource
earlier than expected. Likely, this is a very rare scenario but if it
happens, it could be quite hard to identify the root cause, as the
problem will appear only if the object is collected within the
specific timeframe.
By the way, are we speaking about anonymous classes only? I think,
local classes could be updated in the similar manner. Especially given
the fact that now local records don't capture the surrounding "this"
but if we convert the record to an equivalent local class, it will
capture:
public class Test {
void test() {
record R() {} // does not capture Test instance
class C {} // captures Test instance
}
}
Or should we allow explicit 'static' modifier on local classes?
Best regards,
Tagir Valeev.
On Tue, Aug 3, 2021 at 2:47 AM <fo...@univ-mlv.fr> wrote:
>
> We may have some trouble with the usual suspect, Serialization,
> There are classes like exceptions or Swing UI classes that are marked as
> Serializable and can be implemented as an anonymous class.
> In that case, removing the backpointer if it is not used may change the
> serialization format.
>
> And yes, an anonymous class do not have a "stable" name but people do not
> seem to care too much about that ...
>
> Rémi
>
> ----- Original Message -----
> > From: "Brian Goetz" <brian.go...@oracle.com>
> > To: "Liam Miller-Cushon" <cus...@google.com>
> > Cc: "Remi Forax" <fo...@univ-mlv.fr>, "John Rose" <john.r.r...@oracle.com>,
> > "amber-spec-experts"
> > <amber-spec-experts@openjdk.java.net>
> > Sent: Lundi 2 Août 2021 20:18:56
> > Subject: Re: [External] : Re: Minor improvement to anonymous classes
>
> > FWIW, making this fix not only reduces the memory leak risk, but has a
> > number of nice follow-on benefits that can often trigger further
> > follow-on benefits:
> >
> > - fewer fields, so reduced footprint;
> > - fewer fields might mean more objects fall under the scalarization
> > threshold, when applicable;
> > - less work in constructors;
> > - shorter constructors mean more constructors fall under the inlining
> > threshold;
> > - more inlining might lead to other optimizations.
> >
> > So it wouldn't surprise me to see macro-level effects even on programs
> > without memory leaks.
> >
> >> I filed https://bugs.openjdk.java.net/browse/JDK-8271623
> >> <https://bugs.openjdk.java.net/browse/JDK-8271623> to track that
> > > enhancement.
