Would doing this make anything better enough to outweigh Martin and I needing to deal with one more incompatible codebase?
-Doug On 9/13/19 11:10 AM, fo...@univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *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 <fo...@univ-mlv.fr > <mailto: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 > > 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 >