Deprecation beyond the level of types

[Alex Buckley]

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