RFR: jsr166 integration 2019-09

forax at univ-mlv.fr forax at univ-mlv.fr
Fri Sep 13 16:43:56 UTC 2019


----- Mail original -----
> De: "Doug Lea" <dl at cs.oswego.edu>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Martin Buchholz" <martinrb at google.com>
> 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>
> Envoyé: Vendredi 13 Septembre 2019 17:19:21
> Objet: Re: RFR: jsr166 integration 2019-09

> Would doing this make anything better enough to outweigh Martin and I
> needing to deal with one more incompatible codebase ?

I believe the answer is the question :)

Android (d8 in fact) is able to desugar private access with nestmates since last April,
your latest backport target 9 which is not supported anymore, so when you will move the backport to support Java 11,
this tool can become handy. 

> 
> -Doug

Rémi

> 
> 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