java - Is there a way to compare lambdas? -

say have list of object defined using lambda expressions (closures). there way inspect them can compared?

the code interested in is

    list<strategy> strategies = getstrategies();     strategy = (strategy) this::a;     if (strategies.contains(a)) { // ... 

the full code is

import java.util.arrays; import java.util.list;  public class closureequalsmain {     interface strategy {         void invoke(/*args*/);         default boolean equals(object o) { // doesn't compile             return closures.equals(this, o);         }     }      public void a() { }     public void b() { }     public void c() { }      public list<strategy> getstrategies() {         return arrays.aslist(this::a, this::b, this::c);     }      private void teststrategies() {         list<strategy> strategies = getstrategies();         system.out.println(strategies);         strategy = (strategy) this::a;         // prints false         system.out.println("strategies.contains(this::a) " + strategies.contains(a));     }      public static void main(string... ignored) {         new closureequalsmain().teststrategies();     }      enum closures {;         public static <closure> boolean equals(closure c1, closure c2) {             // doesn't compare contents              // others immutables e.g. string             return c1.equals(c2);         }          public static <closure> int hashcode(closure c) {             return // hashcode can detect duplicates set<strategy>         }          public static <closure> string asstring(closure c) {             return // better object.tostring();         }     }          public string tostring() {         return "my-closureequalsmain";     } } 

it appear solution define each lambda field , use fields. if want print out method called, better off using method. there better way lambda expressions?

also, possible print lambda , human readable? if print this::a instead of

closureequalsmain$$lambda$1/821270929@3f99bd52 

get like

closureequalsmain.a() 

or use this.tostring , method.

my-closureequalsmain.a(); 

this question interpreted relative specification or implementation. obviously, implementations change, might willing rewrite code when happens, i'll answer @ both.

it depends on want do. looking optimize, or looking ironclad guarantees 2 instances (or not) same function? (if latter, you're going find @ odds computational physics, in problems simple asking whether 2 functions compute same thing undecidable.)

from specification perspective, language spec promises result of evaluating (not invoking) lambda expression instance of class implementing target functional interface. makes no promises identity, or degree of aliasing, of result. design, give implementations maximal flexibility offer better performance (this how lambdas can faster inner classes; we're not tied "must create unique instance" constraint inner classes are.)

so basically, spec doesn't give much, except 2 lambdas reference-equal (==) going compute same function.

from implementation perspective, can conclude little more. there (currently, may change) 1:1 relationship between synthetic classes implement lambdas, , capture sites in program. 2 separate bits of code capture "x -> x + 1" may mapped different classes. if evaluate same lambda @ same capture site, , lambda non-capturing, same instance, can compared reference equality.

if lambdas serializable, they'll give state more easily, in exchange sacrificing performance , security (no free lunch.)

one area might practical tweak definition of equality method references, because enable them used listeners , unregistered. under consideration.

i think you're trying is: if 2 lambdas converted same functional interface, represented same behavior function, , have identical captured args, they're same

unfortunately both hard (for non-serializable lambdas, can't @ components of that) , not enough (because 2 separately compiled files convert same lambda same functional interface type, , wouldn't able tell.)

the eg discussed whether expose enough information able make these judgments, discussing whether lambdas should implement more selective equals/hashcode or more descriptive tostring. conclusion not willing pay in performance cost make information available caller (bad tradeoff, punishing 99.99% of users benefits .01%).

a definitive conclusion on tostring not reached, left open revisited in future. however, there arguments made on both sides on issue; not slam-dunk.