FunctionalInterface as a rule in the matching interfaces ?

[Zhong Yu]

Some of these don't feel like "functions", e.g. Formattable, it's
unlikely that anyone would use lambda expression to instantiate them.

What is the general guideline to apply @FunctionalInterface? For
example, why should AutoCloseable be marked as @FI?

Zhong Yu

On Thu, Aug 1, 2013 at 7:28 AM, Jean-Baptiste Bugeaud <bugeaud at gmail.com> wrote:
> Hello,
>
> As a follow-up from Joe Darcy's proposal (2013-02-06) to add
> @FunctionalInterface to some interfaces matching the requirements of
> FI.
>
> I propose that this improvement is applied to all the VM Java libs.
>
> Doing a quick search, I've found some interfaces are not tagged as
> FunctionaInterfaces but clearly look good candidates :
>
> Here is the list of public API I have found so far :
>
> java.security.PriviledgeAction
> java.awt.event.ActionListener
> java.lang.util.concurrent.Callable
> java.util.Formattable
> javax.management.remote.JMXAddressable
> javax.naming.Referenceable
> java.awt.print.Printable
>
> Private packages also have some :
>
> sun.nio.ch.Cancelable
> sun.nio.ch.Groupable
> sun.net.www.http.Hurryable
> sun.misc.Timeable
> sun.awt.image.ImageFetchable
> sun.jvm.hotspot.utilities.soql.Callable
> com.sun.jdi.Locatable
>
> Tier lib used/derivated are also impacted (just FYI as it might be out
> of scope of OpenJDK) :
>
> com.sun.xml.internal.ws.api.config.management.Reconfigurable
> com.sun.xml.internal.ws.api.config.management
> com.sun.corba.se.spi.ior.MakeImmutable
> jdk.internal.org.objectweb.asm.util.ASMifiable
> jdk.internal.org.objectweb.asm.util.Textifiable
>
> Some interfaces got two methods 1 "functional like" and 1 getter.
>
> I propose to put the getter with a default and let the function
> unimplemented so matching with the lambda.
>
> Hence, the changes should be :
> javax.security.auth.Destroyable : remove the default from destroy()
> javax.security.auth.Refreshable : add a default to false to isCurrent()
> javax.script.Compilable : add a default to the version with String
> parameter (or the Reader version ?)
>
> java.nio.file.Watchable : add a default on the method without
> modifiers calling the method with modifiers but with empty array
>
> javax.accessibility.AccessibleStreamable : add a default version to
> getMimeTypes() returning a default raw byte stream mime type like
> application/octet-stream for instance
>
> sun.awt.SubRegionShowable : add a default to showIfNotLost()
>
> More complex cases exists like :
>
> java.lang.Appendable, lot of methods but for the same semantics,
> should we provide defaults for variants and make it @FI ?
>
> java.lang.Cloneable : clearly here it would be nice to get a defaulted
> clone() as it will improve/ease the clonable semantics (implementing
> Clonable will bring the default requirement). Here I am assuming there
> is no side effect of droping cases where you declare Clonable but did
> not implement clone(). Is it so ?
>
> Please forgive my post if this suggestion has not already been
> debatted but I neither found it in the ML search on GG nor in the hg
> revs.
> Also, please not that if the idea is followed, we should performe a
> more comprehensive search, as mine is only done starting on all
> "*able.java" files at this time.
>
> Best Regards,
> JB (bjb at dev.java.net)