Currently (JDK 8), the JDK tool guides come in two flavors, and should
only differ in the content of the examples, and not in any
specification-related text. Yes, you found a Windows version for
javac.html, but there is also a Unix version, here:
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
Having two separate documents is "annoying", and that is something else
we are looking at.
-- Jon
On 1/22/17 10:15 AM, Stephan Herrmann wrote:
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.herrm...@berlin.de>
À: jigsaw-dev@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" <rfscho...@apache.org>
À: jigsaw-dev@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.herrm...@berlin.de> wrote:
On 01/21/2017 06:52 PM, fo...@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
