Repository navigation
AvoidCommonTypeNames false positives when using --release #5957
Description
Using Error Prone 2.50 and compiling with the --release option, the AvoidCommonTypeNames checker is sometimes including java.lang.X.Y classes, when really there is no reason to warn about clashes with those since they are not imported automatically with their undotted name.
Example (using Java 25 with --release 25):
Info.java:1: warning: [AvoidCommonTypeNames] Info clashes with java.lang.ProcessHandle.Info
class Info {}
^
(see https://errorprone.info/bugpattern/AvoidCommonTypeNames)
I think this was introduced by https://github.com/google/error-prone/commit/924cb63735c9e6e44b0362b8ed9fbcfdf1dc8d9d/. The getSymbols call sometimes includes inner classes that getSymbolsByName does not, varying on both the Java version and the --release version:
| Java version | --release version | Classes |
|---|---|---|
| 21 | 8 | Character.UnicodeScript |
| 25 | 8 | Character.UnicodeScript |
| 21 | 11 | StackWalker.StackFrame |
| 25 | 11 | none |
| 21 | 17 | StackWalker.StackFrame, Thread.State, Character.UnicodeScript |
| 25 | 17 | System.LoggerFinder, Character.UnicodeScript |
| 21 | 21 | none |
| 25 | 21 | System.LoggerFinder, ProcessHandle.Info |
| 25 | 25 | ProcessHandle.Info |
Activity
cpovirk commentedon Jul 18, 2026
Interesting, thanks. I wonder if
Symtabis not quite the right tool for this job, similar to how we found that it might not have been the right tool for the job in #5791. I think we've worried before that alternatives can be expensive, but—assuming that there is a proper alternative here, as seems especially likely for a Java 9+ (modular) compilation—I'd hope we don't have to worry about expense because of the caching of the result. Or we just hard-code the list ofjava.langclasses and write a test to nudge us to update it when new ones are added....AzazelSensei commentedon Aug 13, 2026
Opened #6023