Loosening requirements for super() invocation
Nathan Reynolds
numeralnathan at gmail.com
Wed Jan 18 02:00:53 UTC 2023
> To me it seems like an escaping this-reference is safe if the following
condition is fulfilled: One can make sure that the this-reference is only
stored by the method to which it is passed as argument, it is not used in
any other way before the constructor has completed.
The method or class has to be final. Otherwise, a deriving class can
override and now "this" escapes.
On Tue, Jan 17, 2023 at 5:55 PM Jens Lideström <jens.lidestrom at fripost.org>
wrote:
> On 2022-12-30 17:48, Brian Goetz wrote:
> > One thing that makes me a little uncomfortable is that @SW usually is
> used to say “the compiler can’t prove this is safe, but I am asserting it
> is.” But this is different; the compiler has discovered the class is
> unsafe,
>
> Is an escaping this-reference really always an unacceptable problem?
>
> To me it seems like an escaping this-reference is safe if the following
> condition is fulfilled: One can make sure that the this-reference is only
> stored by the method to which it is passed as argument, it is not used in
> any other way before the constructor has completed.
>
> Looking at the diff in Archie's branch [1], it seems like most cases are
> not problematic.
>
> [1]:
> https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:ThisEscape
>
> In most cases in the diff the this-reference escapes to be able to do the
> following:
>
> * Set up a circular relationship with another object.
> * Register a Cleaner.
> * Register a listener.
>
> Sometimes an object might not be considered to be properly constructed
> without doing such things. It seems useful to be able to rely on the
> constructor to complete them.
>
> Regards,
> Jens Lideström
>
> On 2022-12-30 17:48, Brian Goetz wrote:
> > Nice.
> >
> > One thing that makes me a little uncomfortable is that @SW usually is
> used to say “the compiler can’t prove this is safe, but I am asserting it
> is.” But this is different; the compiler has discovered the class is
> unsafe, and @SW is saying “I know, I know, stop telling me.” So I think
> there’s an additional documentation opportunity here where, for the classes
> we had to annotate with @SW, we include an additional @apiNote of the form
> “This class behaves badly, oops”, with a link to a common doc page
> explaining the problem. (While we don’t have to do this necessarily
> immediately, the chance of it falling on the floor if we don’t are
> higher.). Basically, what you’ve identified is that there are a number of
> classes in the JDK which fail to follow best practices with regard to
> self-use from constructors. We can’t turn back the clock, but we can mark
> these as “don’t code like my brother”, so people see these patterns of
> coding and realize they are not to be emulated.
> >
> > I also see in the code that there are two separate categories,
> LeakingThisInConstructor and this-escape; what’s the difference?
> >
> >
> >
> >> On Dec 29, 2022, at 11:10 PM, Archie Cobbs <archie.cobbs at gmail.com
> <mailto:archie.cobbs at gmail.com>> wrote:
> >>
> >> On Wed, Dec 28, 2022 at 4:31 PM Archie Cobbs <archie.cobbs at gmail.com
> <mailto:archie.cobbs at gmail.com>> wrote:
> >>
> >> So fortunately it looks feasible to address these with
> @SuppressWarnings("this-escape") annotations.
> >>
> >> Adding them is probably a good thing in its own right, because they
> would serve as new "Heads up for possible 'this' escape" markers in the
> code where there were none before, especially because this gotcha can be
> pretty hard to spot.
> >>
> >> I'll work on refining the 'this' escape patch to use
> @SuppressWarnings instead of build flags, and then update this thread when
> that's done.
> >>
> >>
> >> OK I have a draft of this. It's still a "draft" because I don't have
> the ability to build locally for every platform, so I'm having trouble
> provoking all the warnings from Java code that is platform-specific. And
> the automated github builds take a long time and then only report one more
> new warning, making for an impossibly slow feedback loop (if anyone is
> interested in helping out, that would be awesome and it's very easy).
> >>
> >> In any case, the good news is that fewer @SupppressWarnings annotations
> than I thought are required. In part this is because there were some
> redundant warnings being generated, which is now fixed.
> >>
> >> Here are the updated stats. These numbers are promisingly low.
> >>
> >> The first column is the number of @SupppressWarnings annotations added
> to eliminate all of the new 'this' escape warnings I'm able to provoke.
> >>
> >> #SUPPRESS #FILES MODULE
> >> 47 3077 java.base
> >> 0 128 java.compiler
> >> 0 18 java.datatransfer
> >> 86 2899 java.desktop
> >> 0 10 java.instrument
> >> 0 23 java.logging
> >> 4 330 java.management
> >> 0 16 java.management.rmi
> >> 5 199 java.naming
> >> 15 142 java.net.http
> >> 0 20 java.prefs
> >> 4 106 java.rmi
> >> 0 15 java.scripting
> >> 0 1 java.se <
> https://urldefense.com/v3/__http://java.se__;!!ACWV5N9M2RV99hQ!L6fbZinPZagPgDKlgLerhi4QrI3gEtnjcVISBKwwhyNWx6vQLuwL2nKnjRMGg4yMeBEbWn6k5OGYUlLj5kvW3Ws$
> >
> >> 7 216 java.security.jgss
> >> 0 30 java.security.sasl
> >> 0 23 java.smartcardio
> >> 1 77 java.sql
> >> 0 56 java.sql.rowset
> >> 0 5 java.transaction.xa
> >> 39 1848 java.xml
> >> 32 271 java.xml.crypto
> >> 3 20 jdk.accessibility
> >> 0 21 jdk.attach
> >> 0 18 jdk.charsets
> >> 53 333 jdk.compiler
> >> 1 76 jdk.crypto.cryptoki
> >> 0 35 jdk.crypto.ec <
> https://urldefense.com/v3/__http://jdk.crypto.ec__;!!ACWV5N9M2RV99hQ!L6fbZinPZagPgDKlgLerhi4QrI3gEtnjcVISBKwwhyNWx6vQLuwL2nKnjRMGg4yMeBEbWn6k5OGYUlLjMLnBEws$
> >
> >> 0 11 jdk.crypto.mscapi
> >> 4 68 jdk.dynalink
> >> 0 3 jdk.editpad
> >> 10 942 jdk.hotspot.agent
> >> 3 56 jdk.httpserver
> >> 0 5 jdk.incubator.concurrent
> >> 0 50 jdk.incubator.vector
> >> 0 3 jdk.internal.ed
> >> 1 61 jdk.internal.jvmstat
> >> 1 113 jdk.internal.le
> >> 1 52 jdk.internal.opt
> >> 5 209 jdk.internal.vm.ci <
> https://urldefense.com/v3/__http://jdk.internal.vm.ci__;!!ACWV5N9M2RV99hQ!L6fbZinPZagPgDKlgLerhi4QrI3gEtnjcVISBKwwhyNWx6vQLuwL2nKnjRMGg4yMeBEbWn6k5OGYUlLjlAiOBII$
> >
> >> 0 1 jdk.internal.vm.compiler
> >> 0 1 jdk.internal.vm.compiler.management
> >> 0 18 jdk.jartool
> >> 5 228 jdk.javadoc
> >> 0 41 jdk.jcmd
> >> 18 64 jdk.jconsole
> >> 10 124 jdk.jdeps
> >> 25 254 jdk.jdi
> >> 0 1 jdk.jdwp.agent
> >> 0 263 jdk.jfr
> >> 0 77 jdk.jlink
> >> 1 80 jdk.jpackage
> >> 6 88 jdk.jshell
> >> 0 4 jdk.jsobject
> >> 1 11 jdk.jstatd
> >> 0 281 jdk.localedata
> >> 1 25 jdk.management
> >> 0 19 jdk.management.agent
> >> 0 15 jdk.management.jfr
> >> 0 16 jdk.naming.dns
> >> 0 8 jdk.naming.rmi
> >> 0 11 jdk.net <
> https://urldefense.com/v3/__http://jdk.net__;!!ACWV5N9M2RV99hQ!L6fbZinPZagPgDKlgLerhi4QrI3gEtnjcVISBKwwhyNWx6vQLuwL2nKnjRMGg4yMeBEbWn6k5OGYUlLjKWHeJYA$
> >
> >> 0 2 jdk.nio.mapmode
> >> 0 11 jdk.random
> >> 0 37 jdk.sctp
> >> 0 30 jdk.security.auth
> >> 0 16 jdk.security.jgss
> >> 0 9 jdk.unsupported
> >> 0 8 jdk.unsupported.desktop
> >> 0 94 jdk.xml.dom
> >> 1 14 jdk.zipfs
> >>
> >> Code available here <
> https://urldefense.com/v3/__https://github.com/archiecobbs/jdk/tree/ThisEscape__;!!ACWV5N9M2RV99hQ!L6fbZinPZagPgDKlgLerhi4QrI3gEtnjcVISBKwwhyNWx6vQLuwL2nKnjRMGg4yMeBEbWn6k5OGYUlLjPRWM0ZM$
> >.
> >>
> >> -Archie
> >>
> >> --
> >> Archie L. Cobbs
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230117/db246567/attachment-0001.htm>
More information about the amber-dev
mailing list