On Tue, 17 Jan 2023 15:36:49 GMT, Archie L. Cobbs <d...@openjdk.org> wrote:
> nstead, we could widen the maintenance boundary to the package/module > boundary, and instead ask: Is X public, not final, not sealed, and does X > have a non-private constructor? > > This is not a perfect drawing of that boundary, because it ignores which > packages are exported in a module, but that error is a conservative one, and > it avoids tricky issues with how files are compiled. > > This would eliminate your false positive example above, albeit not for the > reasons you state, but rather simply because `Bundle` is package-private. > From previous test, it reduces warnings in the JDK by 36%. > > Your thoughts? I agree with this conclusion. Also, even if a class is public, our question should be: is this class in a non-exported package? Because, if so, even a public class can be "implementation specific". ------------- PR: https://git.openjdk.org/jdk/pull/11874
