[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-dev
Subject:    Direct extension method use warning
From:       reinier () zwitserloot ! com (Reinier Zwitserloot)
Date:       2010-12-13 5:48:51
Message-ID: AANLkTinn5yfDnk==3X7tCvTYVmB6+d3eqyJr8F9sJr2D () mail ! gmail ! com
[Download RAW message or body]

Well, this begs the following question:

What happens when some code in method CALLER calls method EXTENSION, which
is an extension that points to Collections.SORT, and EXTENSION is *NOT*
annotated with @Deprecated, but Collections.SORT *IS*. Does CALLER get a
deprecation warning?

If I recall correctly, the defender method spec does not mention how this
would work. However, if we now say that the following will hold:

 1. Declaring an extension method will generate a warning on the 'public
void foo() default SomeClass.someDeprecatedMethod();' line, which can be
ignored via the usual mechanisms.

 2. Calling an extension method does *NOT* generate a deprecation warning
unless the default method is itself marked as deprecated, i.e., it is
declared like so: "@Deprecated public void foo() default
SomeClass.whatever();". In other words, calling "public void foo() default
SomeClass.someDeprecatedMethod();" does not count as using deprecated API.

These rules are no more surprising than any other (one could argue they are
the least surprising, I guess, but that might be personal bias), and solve
this problem without requiring a new annotation. If you control both
interface and collections-esque class, you can mark Collections.sort as
deprecated, point to this from List, and suppress the deprecation warning
there. The users of your library will get the intended effect: Calling
Collections.sort gets you a warning, but calling list.sort() doesn't.
overriding sort() won't, either.

I have a problem with the idea of annotating these methods, and associating
deprecated-esque semantics to them, because they paint a binary picture:
When a method is used as implementation for a defender, then nobody has any
business calling it directly. Experience may bear out that this in practice
holds, but I'm not convinced at this point in time that it will. For
example, I can imagine an implementation of some interface with extension
methods overriding these, but calling on the default implementation as part
of their custom implementation. These would score instant warnings that
would then have to be suppressed, unless we now define that this kind of
behaviour is okay.

Also, more generally, I don't think javac itself should be bogged down with
style checks unless that style check is rock solid (i.e. universally agreed
to as bad form by the entire java community). I'm not sure calling extension
implementations directly counts.

 --Reinier Zwitserloot



On Tue, Dec 7, 2010 at 9:22 AM, Thomas Jung <
thomas.andreas.jung at googlemail.com> wrote:

> > (A further problem with use-site extension methods is the lack of
> reflective
> > discovery.  Consumers of classfiles (such as non-Java compilers like
> JRuby, as
> > well as templating mechanism such as JSP EL) cannot easily find these
> > extension methods.)
>
> Wouldn't it be useful to annotate a method (e.g. Collection.sort) as
> an extension method implementation? Users that invoke the method
> directly would get a (deprecation) warning. (The annotation is not
> strictly necessary as the extension method declaration makes it
> implicitly an extension method implementation.) This warning could
> help to move to the "new style".
>
> Thomas
>
>

[prev in list] [next in list] [prev in thread] [next in thread]