RFR: 8015831: Add lint check for calling overridable methods from a constructor [v11]

[Archie L. Cobbs]

On Tue, 17 Jan 2023 15:53:57 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

> A more complete analysis would analyze the base class + possible subclass combinations, and could exclude some escapes which are harmless (i.e., the base class passes `this` to an overridable method, but no overrides make use of it, and no other ovverides are possible).  But that seems its moving in the opposite direction of what you're looking for?

So far we've stuck to the requirement that whatever analysis we are doing is done on a a per-file basis, one at a time, so analyzing possible class + subclass combinations is currently limited to what's available in a single file.

Now this is not an inviolate requirement, and removing it would certainly enable the analysis to rule out more false positives (as with your example), but it's not something we've really considered doing yet, mainly because of item 2 below.

In the big picture, it seems like our goals are roughly:
1. Be able to detect a high % of the "truly threatening" leaks that are out there (minimize false negatives)
1. Keep the implementation relative simple and minimize compiler performance impact
1. Try to avoid having so many false positives that developers are turned off or annoyed

I think we're pretty good on item 1, although this one somewhat of a speculative judgement call.

For item 2 we're in the right ballpark I think... (others may disagree).

For item 3, this is where there is still some worry and uncertainty. It's not just about what kind of leaks/bugs are out there, it's also that it's hard to predict how humans will react.

So starting with a less aggressive posture, allowing for getting more so over time, is a the more conservative option.

The simplest way to do that is to widen the "maintenance boundary" as mentioned. Now this could impact item 1 but at least any new false negatives would necessarily be contained within a single package/module.

To restate: we can always get more aggressive if that turns out to be warranted. But if you start out too aggressive and the world barfs on it and just turns it off, you've probably missed your chance forever.

-------------

PR: https://git.openjdk.org/jdk/pull/11874