RFR JDK-8167442: Langtools ant build not working after addition of -Xlint:exports
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Oct 11 07:46:31 UTC 2016
----- 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.
More information about the compiler-dev
mailing list