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

[Jan Lahoda]

On 11.10.2016 09:46, forax at univ-mlv.fr wrote:
> ----- 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.

Thanks.

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

Not sure if that's what should be done: the classes are intentionally 
public and exported, so that (some) clients may use them. But I am not 
sure if the use will be widespread enough to force jdk.jdi to all other 
clients of the API as well. (Esp. given those that need to use a 
JDI-related method can simply do "requires jdk.jdi" themselves.)

Jan

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