FunctionalInterface as a rule in the matching interfaces ?
zhong.j.yu at gmail.com
Thu Aug 1 15:14:04 UTC 2013
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?
On Thu, Aug 1, 2013 at 7:28 AM, Jean-Baptiste Bugeaud <bugeaud at gmail.com> wrote:
> As a follow-up from Joe Darcy's proposal (2013-02-06) to add
> @FunctionalInterface to some interfaces matching the requirements of
> 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 :
> Private packages also have some :
> Tier lib used/derivated are also impacted (just FYI as it might be out
> of scope of OpenJDK) :
> 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
> 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)
More information about the core-libs-dev