> De: "Martin Buchholz" <marti...@google.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "loom-dev" > <loom-...@openjdk.java.net>, "David Holmes" <david.hol...@oracle.com>, "Doug > Lea" <d...@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:fo...@univ-mlv.fr | > fo...@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
