Reusing module name token `*` in -d

Stephan Herrmann stephan.herrmann at berlin.de
Sun Jan 22 18:15:14 UTC 2017


Thanks, Jon,

FWIW, I did search on http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html
This brought no result for the simple reason, that no connection is made from Xlint to @SW.

Additionally, it feels a bit odd that such documentation should be platform-dependent
(see the "windows" path segment in the above URL).

Do you perhaps have a draft of what javac.html will look like for Java 9?

best,
Stephan


On 01/22/2017 07:00 PM, Jonathan Gibbons wrote:
> 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