Deprecation beyond the level of types
alex.buckley at oracle.com
Tue Apr 24 19:32:28 UTC 2018
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,
More information about the jigsaw-dev