RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13]

[Vicente Romero]

On Wed, 14 May 2025 18:25:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671:
> 
>> 5669:     }
>> 5670: 
>> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {
> 
> For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc.
> 
> Or is there a reason to given up the sharp(er) type and re-create it using the switch?

I guess the motivation was to have all this related code in one place, if this code is split into several overloaded methods then I guess an entity, a class, should probably be defined to contain all this code. Dunno I guess the current solution seemed more self-contained to me

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2091858747