Loosening requirements for super() invocation
Brian Goetz
brian.goetz at oracle.com
Fri Dec 30 16:48:14 UTC 2022
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/20221230/ec1c55b9/attachment-0001.htm>
More information about the amber-dev
mailing list