Java Platform Module System - Xlint?

[Stephan Herrmann]

 From JLS 9.6.4.5:

"For other kinds of warnings, compiler vendors should document the strings they support
for @SuppressWarnings. Vendors are encouraged to cooperate to ensure that the same
names work across multiple compilers."

Any suggestions, how we can engage in such cooperation?
In particular: where can I read what exactly [1] the new -Xlint tokens of javac mean,
and whether or not all -Xlint tokens work the same also for @SuppressWarnings?

Stephan

[1] I don't think explanations like "Warns about module system related issues"
are sufficient for coordination.

On 06.06.2017 12:37, Stephan Herrmann wrote:
> I didn't see an answer to this question:
> 
> 
> On 30.04.2017 23:45, Stephan Herrmann wrote:
>> On 30.04.2017 17:47, Alan Bateman wrote:
>>> On 30/04/2017 12:10, Stephan Herrmann wrote:
>>>
>>>> :
>>>>
>>>> Java 9 could make "API leaks" either illegal or ineffective and thus rule out
>>>> an entire category of ill-formed programs, which to-date must unfortunately
>>>> be accepted by module-unaware compilers:
>>>>
>>>>   (A) Java 9 has the opportunity to say that the declaration of m1 is illegal,
>>>>   because it publicly exposes a non-accessible type, which is broken in
>>>>   every regard.
>>> FWIW, this is -Xlint:exports when using javac, e.g: public class in a non-exported package:
>>>
>>> src/m/p/C1.java:4: warning: [exports] class C2 in module m is not exported
>>>     public q.C2 hello() { return null; }
>>>             ^
>>> 1 warning
>>>
>>> or a non-public class in an exported package:
>>>
>>> src/m/p/C1.java:4: warning: [exports] class C2 in module m is not accessible to clients that require this module
>>>     public C2 hello() { return null; }
>>>            ^
>>> 1 warning
>>>
>>> -Alan
>>
>> Thanks for the hint.
>>
>> My obvious question: Is this specified (where?), or javac's own deliberation?
>> Even if the latter, it would be great to see a list of jigsaw related lints.
> 
> I see several additions to Xlint in https://docs.oracle.com/javase/9/tools/javac.htm
> 
> Are these Xlint tokens also supported as @SuppressWarnings tokens? If so, we should
> definitely coordinate between compilers, which requires more specific descriptions
> of the warnings in each of those categories. "Issues regarding ..." is not very
> specific :)
> 
> Stephan