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 core-libs-dev
mailing list