Reusing module name token `*` in -d

Jonathan Gibbons jonathan.gibbons at oracle.com
Sun Jan 22 18:00:14 UTC 2017


Stephan, Rémi, et al,

Yes, we need to better document the @SuppressWarnings and lint options 
accepted by javac.

At least part of the problem is that we don't have a good place to write 
such documentation/specification. We are working on that too.

-- Jon

On 1/22/17 8:21 AM, Stephan Herrmann wrote:
> Thanks.
> Is that the documentation that JLS mentions?
> I was expecting s.t. that search engines can find.
> The javac help message doesn't even speak of @SuppressWarnings,
> so are we sure this is the same list?
>
> More specifically: the warning of unresolved "to", is that covered
> by "module" or "exports", or both?
>
> Stephan
>
> On 01/22/2017 03:50 PM, Remi Forax wrote:
>> $javac -X
>>  -Xlint:<key>(,<key>)*
>>         Warnings to enable or disable, separated by comma.
>>         Precede a key by - to disable the specified warning.
>>         Supported keys are:
>>           all                  Enable all warnings
>>           auxiliaryclass       Warn about an auxiliary class that is 
>> hidden in a source file, and is used from other files.
>>           cast                 Warn about use of unnecessary casts.
>>           classfile            Warn about issues related to classfile 
>> contents.
>>           deprecation          Warn about use of deprecated items.
>>           dep-ann              Warn about items marked as deprecated 
>> in JavaDoc but not using the @Deprecated annotation.
>>           divzero              Warn about division by constant 
>> integer 0.
>>           empty                Warn about empty statement after if.
>>           exports              Warn about issues regarding module 
>> exports.
>>           fallthrough          Warn about falling through from one 
>> case of a switch statement to the next.
>>           finally              Warn about finally clauses that do not 
>> terminate normally.
>>           module               Warn about module system related issues.
>>           options              Warn about issues relating to use of 
>> command line options.
>>           overloads            Warn about issues regarding method 
>> overloads.
>>           overrides            Warn about issues regarding method 
>> overrides.
>>           path                 Warn about invalid path elements on 
>> the command line.
>>           processing           Warn about issues regarding annotation 
>> processing.
>>           rawtypes             Warn about use of raw types.
>>           removal              Warn about use of API that has been 
>> marked for removal.
>>           serial               Warn about Serializable classes that 
>> do not provide a serial version ID.
>>                              Also warn about access to non-public 
>> members from a serializable element.
>>           static               Warn about accessing a static member 
>> using an instance.
>>           try                  Warn about issues relating to use of 
>> try blocks (i.e. try-with-resources).
>>           unchecked            Warn about unchecked operations.
>>           varargs              Warn about potentially unsafe vararg 
>> methods
>>           none                 Disable all warnings
>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Stephan Herrmann" <stephan.herrmann at berlin.de>
>>> À: jigsaw-dev at openjdk.java.net
>>> Envoyé: Dimanche 22 Janvier 2017 15:25:57
>>> Objet: Re: Reusing module name token `*` in -d
>>
>>> On 01/22/2017 02:50 PM, Remi Forax wrote:
>>>> interesting !
>>>>
>>>> It's now a warning that you can exclude with 
>>>> @SuppressWarnings("module"):
>>>>   src/main/java/foo/module-info.java:2: warning: [module] module 
>>>> not found: baz
>>>>   exports foo to baz;
>>>>                  ^
>>>
>>> JLS 9.6.4.5 @SuppressWarnings:
>>> "Compiler vendors should document the warning names they support in 
>>> conjunction
>>>  with this annotation type. Vendors are encouraged to cooperate to 
>>> ensure that
>>>  the same names work across multiple compilers."
>>>
>>> looking forward to seeing this happen,
>>> Stephan
>>>
>>>> Rémi
>>>>
>>>> ----- Mail original -----
>>>>> De: "Robert Scholte" <rfscholte at apache.org>
>>>>> À: jigsaw-dev at openjdk.java.net
>>>>> Envoyé: Samedi 21 Janvier 2017 20:12:37
>>>>> Objet: Re: Reusing module name token `*` in -d
>>>>
>>>>> On Sat, 21 Jan 2017 19:35:28 +0100, Stephan Herrmann
>>>>> <stephan.herrmann at berlin.de> wrote:
>>>>>
>>>>>> On 01/21/2017 06:52 PM, forax at univ-mlv.fr wrote:
>>>>>>> Robert,
>>>>>>> How do you compile these 2 modules with Maven ?
>>>>>>>
>>>>>>> module foo {
>>>>>>>   exports foo to bar;
>>>>>>> }
>>>>>>>
>>>>>>> module bar {
>>>>>>>   requires foo;
>>>>>>> }
>>>>>>>
>>>>>>> when compiling 'foo' javac needs to see if 'bar' exists and when
>>>>>>> compiling 'bar', javac will ask to see 'foo'.
>>>>>>
>>>>>> I don't think so:
>>>>>>
>>>>>> "It is permitted for the to clause of an exports or opens 
>>>>>> statement to
>>>>>> specify a module which is not observable."
>>>>>> [lang-vm.html 1.1.2 - 2017/1/9]
>>>>>>
>>>>>> I assume this will eventually (when??) become part of JLS, right?
>>>>>>
>>>>>> cheers,
>>>>>> Stephan
>>>>>
>>>>>
>>>>> Confirmed. I've added an integration-test to the 
>>>>> maven-compiler-plugin,
>>>>> works as expected. No need for cross reference dependencies.
>>>>>
>>>>> thanks,
>>>>> Robert
>



More information about the jigsaw-dev mailing list