Re: Method references to same instance+method yield different method reference instances

[Timo Kinnunen]

Hi, 


OK, maybe I’m just missing something here, but the whole caching issue seems like a red herring to me and the underlying issue is much simpler than that. 


As originally reported, a method reference is added as a listener but can’t be removed afterwards. Now what is going to happen when a listener is registered to something? It gets added to a Collection of some sort, a List or a Set, maybe. And why would a Collection not recognize a completely identical Object as equivalent to a one it contains? Because the class implementing the functional interface doesn’t override hashCode() and equals()!


Now the fun part, how might that work..? The input given is just a this::eventHandler expression, both parts are significant but nothing else is. Caching, side-effects in general are a no-no. The Lambda implementation classes are unrelated to one another and don’t share that many common APIs, so basic communication between them is already tricky, but maybe there’s a way.. 


.. By using Strings as keys, without making it a habit. A pseudo code implementation:


public boolean equals(Object other) {

 return Objects.equals(String.valueOf(this), String.valueOf(other));

}


public int hashCode() {

 return String.valueOf(this).hashCode();

}


public String toString() {

 return System.identityHashCode(targetReceiver) + targetMethodSignatureAsString;

// same as ((int) <this-pointer-from-caller>) + <unique-id-of-eventHandler-as-in-constant-pool>;

}


Functional, pure, not a single cache is sight.









-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: John Rose
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎22‎:‎30
To: Timo Kinnunen
Cc: Remi Forax, lambda-dev at openjdk.java.net






On Jan 20, 2014, at 10:34 AM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:


why the JVM links two identical invokedynamic instructions separately I don’t know



http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/java/lang/invoke/package-info.java



 * In an application which requires dynamic call sites with individually

 * mutable behaviors, their bootstrap methods should produce distinct

 * {@link java.lang.invoke.CallSite CallSite} objects, one for each linkage request.

 * Alternatively, an application can link a single {@code CallSite} object

 * to several {@code invokedynamic} instructions, in which case

 * a change to the target method will become visible at each of

 * the instructions.




It's a user choice, actually.  But that choice doesn't change Remi's observation about caching.

— John