Loosening requirements for super() invocation
Brian Goetz
brian.goetz at oracle.com
Wed Jan 18 02:01:41 UTC 2023
On 12/30/2022 4:37 PM, Jens Lideström 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.
This is a popular misconception. An escaping this also voids the final
field visibility guarantees (see JLS 17.5).
(And, even in the absence of these considerations, errors involving
escape (such as calling overridable instance methods from constructors)
are difficult to reason about.)
> 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.
While we didn't really understand this in 1995 when a lot of such code
was being written, the correct response in these cases is usually to use
a factory and a private constructor. (Registering a listener in this
way for non-final classes leaves you open to subtle timing bugs.)
Basically, these behaviors don't mix well with extension.
> 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
>>
More information about the amber-dev
mailing list