RFR JDK-8167442: Langtools ant build not working after addition of -Xlint:exports

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Jan Lahoda" <jan.lahoda at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Mardi 11 Octobre 2016 08:55:34
> Objet: Re: RFR JDK-8167442: Langtools ant build not working after addition of -Xlint:exports

Hi Jan,

> On 11.10.2016 08:11, Remi Forax wrote:
>> I don't think it's a good idea to try to hide these kind of warning
>> under the carpet.
> 
> Bugs have been filled to every module in OpenJDK for which this warning
> is reported:
> https://bugs.openjdk.java.net/browse/JDK-8167176
> https://bugs.openjdk.java.net/browse/JDK-8167178
> https://bugs.openjdk.java.net/browse/JDK-8167180
> https://bugs.openjdk.java.net/browse/JDK-8167181
> https://bugs.openjdk.java.net/browse/JDK-8167182
> https://bugs.openjdk.java.net/browse/JDK-8167185
> https://bugs.openjdk.java.net/browse/JDK-8167187
> 
> The warnings have been disabled in the make buildsystem so that the lint
> can be integrated (I suspect that first trying to fix each and every
> violation and then introduce the lint could prove to be too difficult).

ok,
+1 if it's a temporary fix.

> 
>>
>> It means that the methods are public or the class is in an exported
>> package but it should not.
> 
> In the specific jdk.jshell case (which we are discussing here), the
> warning is even more strict: in jdk.jshell there are methods like:
> JDIExecutionControl.vm()com.sun.jdi.VirtualMachine
> 
> com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi
> module which the jdk.jshell module does not "re-export" (i.e. the
> jdk.jshell module does not requires public jdk.jdi). So every client of
> this method needs to require jdk.jdi themselves. Whether that is a
> problem in this specific case, I am not sure (I am personally not sure
> if the use of the offending classes in jdk.jshell will be mainstream
> enough to push jdk.jdi to each client of the API).

Using require transitive is one way to solve the warnings,
but i agree with you that this is not the good way to solve that issue.
Here, i think the API should either not be public or put in a non exported package, even if it means creating a non exported package for things like Util.

> 
>>
>> Hiding this kind of info is harmful IMO.
> 
> In this specific case, we are discussing disabling the lint in the
> developer-only ant build script for langtools. The current state blocks
> everyone using the developer-only ant build script (or forces them to
> use private workaround), and I am not sure we should rush some decision
> on whether jdk.jshell should requires public jdk.jdi just to unblock
> people that are using ant.
> 
> Jan

Rémi

> 
>>
>> Rémi
>>
>> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
>> <jan.lahoda at oracle.com> wrote:
>>
>>     Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8167442
>>
>>     Proposed solution is to disable the exports lint when compiling the
>>     langtools sources (the lint is disabled for the jdk.jshell module when
>>     building using the make buildsystem).
>>
>>     Webrev:
>>     http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>>
>>     Any feedback is welcome.
>>
>>     Thanks,
>>           Jan
>>
>>
>> --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.