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 <buge...@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 (b...@dev.java.net)
