From JLS

"For other kinds of warnings, compiler vendors should document the strings they 
for @SuppressWarnings. Vendors are encouraged to cooperate to ensure that the 
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 
and whether or not all -Xlint tokens work the same also for @SuppressWarnings?


[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/ 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/ warning: [exports] class C2 in module m is not accessible to 
clients that require this module
    public C2 hello() { return null; }
1 warning


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

Are these Xlint tokens also supported as @SuppressWarnings tokens? If so, we 
definitely coordinate between compilers, which requires more specific 
of the warnings in each of those categories. "Issues regarding ..." is not very
specific :)


Reply via email to