RFR: jsr166 integration 2019-09

Doug Lea dl at cs.oswego.edu
Fri Sep 13 15:19:21 UTC 2019


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, forax at univ-mlv.fr wrote:
> 
> 
> ------------------------------------------------------------------------
> 
>     *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 <forax at univ-mlv.fr
>     <mailto: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
> 
> 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
> 




More information about the loom-dev mailing list