On 4/24/2018 11:55 AM, Stephan Herrmann wrote:
On 03.04.2018 02:49, Alex Buckley wrote:
You're right -- the JLS does not mandate a warning when compiling code
on the classpath that uses code in deprecated modules.
Wouldn't it be more consistent to give such warnings?
Why should writing code in an unnamed vs. named module make a
difference in whether or not I'm seeing deprecation warnings?
Consistent yes, usable no. The possibility of a module being deprecated
is not understood by vast amounts of code on the classpath written
before Java SE 9. If deprecating a module implicitly deprecated all its
exported public types, then code on the classpath would start to see
warnings "out of thin air" -- nothing that the classpath code refers to
by name would be explicitly deprecated. We thought such "action at a
distance" was too great a burden to impose on classpath code. (And we
are consistent in not imposing "action at a distance" -- applying
@SuppressWarnings to a module declaration does NOT implicitly suppress
warnings for all the type declarations in the module.)
Would you consider a compiler that issues such warnings as violating JLS?
A compiler can only issue _deprecation warnings_ (and their brother,
_removal warnings_) where the JLS mandates it. But a compiler is free to
issue other kinds of warnings anywhere. For example, javac has
-Xlint:dep-ann which issues warnings related to, but not exactly about,
deprecation.
Alex
