RFR: jsr166 integration 2019-09

[forax at univ-mlv.fr]

> De: "Martin Buchholz" <martinrb at google.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "loom-dev"
> <loom-dev at openjdk.java.net>, "David Holmes" <David.Holmes at oracle.com>, "Doug
> Lea" <dl at cs.oswego.edu>
> Envoyé: Jeudi 12 Septembre 2019 16:20:12
> Objet: Re: RFR: jsr166 integration 2019-09

> On Thu, Sep 12, 2019 at 1:48 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> This remember me something,
>> we should refactor most of the the package-private final methods (and the
>> corresponding constructors) at least inside java.lang/java.util to make them
>> private, there is no need to make them package-private anymore given that since
>> Java 11 the compiler emits nestmate attributes instead of generating the method
>> access$XXX.

>> Maybe i should write a bytecode analyzer for that ?

> Right! Going the other way it was fairly easy to trawl through the generated
> bytecode using javap looking for "access$".
> I don't think the nestmates feature is really complete until there is an easy
> tool to find all the package-private elements accessed only within their nest.

[ https://github.com/forax/nestmate-tidyup/blob/master/NestMateTidyUp.java | https://github.com/forax/nestmate-tidyup/blob/master/NestMateTidyUp.java ] 

To reduce the number of dependencies to 0, it uses the jdk internal version of ASM, so the command line is 
java --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED NestMateTidyUp.java 

It crawles java.base to find the fields/methods/constructors that should be declared private. 

weirdly, the compiler (javac) also generates some package private fields (those pesky this$0) if the class itself is package private (i believe). 

Rémi