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

[Jan Lahoda]

On 11.10.2016 17:22, Jonathan Gibbons wrote:
>
>
> On 10/10/16 11:55 PM, Jan Lahoda wrote:
>> 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).
>>
>>>
>>> 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).
>
> Why not use "requires public"?  What is the downside?

That's of course the simplest solution. My concern here is that this is 
(a small) help to a possibly smaller group of clients that will use the 
JDI-related methods, but we would also push the jdk.jdi dependency to a 
possibly larger group clients that don't need these JDI methods. I am a 
little bit on the fence on whether we should use requires public jdk.jdi 
or not. So, I was hoping we could discuss if we want the requires public 
or @SuppressWarnings for the specific methods. (Or, as I overall don't 
think this is a significant problem, we could also discuss dropping this 
particular check from the lint.)

Jan

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