5 ms·

I'm not familiar with the issue: what makes Java's lambdas/closures fake? Is it that bound variables need to be effectively final?

hinkley 7y ago
I don’t know if they’ve done anything new, but as originally implemented, they were inner classes.
- erik_seaberg 7y ago
  The inner class gets copies of the variables, so imperative code that wants to reassign them isn't allowed because it probably won't do what you expected. The goal is not to GC stack frames. But I'm not sure why the didn't create an inner class to hold the closed-over variables in non-final fields (moving them from the stack to the heap) for both the function and all closures it creates. (Obligatory "doctor, it hurts when I use mutable state!")
  - kjeetgill 7y ago
    Ah, gotcha. Honestly, I always use this as an example of one of the subtle design points that I really appreciate Java for. Nitpick, but saying copies in Java can get confusing. Both primitives and references are bound by value. I'm sure you know, but for others: no objects are copied. I always found this limitation had reassuring regularity; it's the same way arguments are bound to function parameters (minus bring final). Local variables being isolated from "other scopes" means that any interthread communication must be mediated through objects.
- kjeetgill 7y ago
  I believe they still are, with the caveat that the bytecode is built at runtime for lambdas not compile time like regular inner classes.
  - pjmlp 7y ago
    Invokedynamic is not related at all to inner classes.
    - kjeetgill 7y ago
      Maybe my memory is a little rusty or I glossed over a bit too much, but I was thinking of how hotspot does lambdas from here[0]. It seems to use the Invokedyanmic Bootstrap method to spin an InnerClass at runtime. To be fair, it's a hotspot thing and not in the JVM spec. [0]: https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/java/lang/invoke/LambdaMetafactory.java#L299 https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/c...
      - pjmlp 7y ago
        Better check out from Brian's talk. Not really, because the class file with invokedynamic bytecodes is supposed to work across all JVM implementations.
        kjeetgill 7y ago
        I think we agree? The bytecode is transferrable because the classfile only contains an invokedynamic that calls the LambdaMetaFactory for bootstrapping. The LambdaMetaFactory is provided by the runtime JVM itself so that linkage dosn't introduce an implementation dependence. Hotspot's just happens to spin an inner class at runtime.
        pjmlp 7y ago
        Yes we agree, I do conceed that I wasn't fully correct.
- pjmlp 7y ago
  They were never implemented that way, rather make use of invokedynamic bytecode. https://youtu.be/Uns1dm3Laq4 https://youtu.be/Uns1dm3Laq4 Android Java is the one making use of anonymous inner classes instead.
deleted 7y ago
[deleted]
paulddraper 7y ago
> Is it that bound variables need to be effectively final? I believe this is it.

hinkley 7y ago

I don’t know if they’ve done anything new, but as originally implemented, they were inner classes.

erik_seaberg 7y ago
The inner class gets copies of the variables, so imperative code that wants to reassign them isn't allowed because it probably won't do what you expected. The goal is not to GC stack frames. But I'm not sure why the didn't create an inner class to hold the closed-over variables in non-final fields (moving them from the stack to the heap) for both the function and all closures it creates. (Obligatory "doctor, it hurts when I use mutable state!")
- kjeetgill 7y ago
  Ah, gotcha. Honestly, I always use this as an example of one of the subtle design points that I really appreciate Java for. Nitpick, but saying copies in Java can get confusing. Both primitives and references are bound by value. I'm sure you know, but for others: no objects are copied. I always found this limitation had reassuring regularity; it's the same way arguments are bound to function parameters (minus bring final). Local variables being isolated from "other scopes" means that any interthread communication must be mediated through objects.
kjeetgill 7y ago
I believe they still are, with the caveat that the bytecode is built at runtime for lambdas not compile time like regular inner classes.
- pjmlp 7y ago
  Invokedynamic is not related at all to inner classes.
  - kjeetgill 7y ago
    Maybe my memory is a little rusty or I glossed over a bit too much, but I was thinking of how hotspot does lambdas from here[0]. It seems to use the Invokedyanmic Bootstrap method to spin an InnerClass at runtime. To be fair, it's a hotspot thing and not in the JVM spec. [0]: https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/java/lang/invoke/LambdaMetafactory.java#L299 https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/c...
    - pjmlp 7y ago
      Better check out from Brian's talk. Not really, because the class file with invokedynamic bytecodes is supposed to work across all JVM implementations.
      - kjeetgill 7y ago
        I think we agree? The bytecode is transferrable because the classfile only contains an invokedynamic that calls the LambdaMetaFactory for bootstrapping. The LambdaMetaFactory is provided by the runtime JVM itself so that linkage dosn't introduce an implementation dependence. Hotspot's just happens to spin an inner class at runtime.
        pjmlp 7y ago
        Yes we agree, I do conceed that I wasn't fully correct.
pjmlp 7y ago
They were never implemented that way, rather make use of invokedynamic bytecode. https://youtu.be/Uns1dm3Laq4 https://youtu.be/Uns1dm3Laq4 Android Java is the one making use of anonymous inner classes instead.

deleted 7y ago

[deleted]

paulddraper 7y ago

> Is it that bound variables need to be effectively final? I believe this is it.