2 ms·

Yet another half-baked implentation of concept. Why in the world closures are limited to the SAM use case is beyond me. It's erasure all over again -- buildin

Yet another half-baked implentation of concept. Why in the world closures are limited to the SAM use case is beyond me. It's erasure all over again -- building a "general" purpose feature suited to one pratical use. It's no wonder that Java has lost its position as the platform on which to innovate and develop new projects. I wish Oracle would be willing to break backwards compatibility in JDK8, and deliver an truly innovative and exciting product. Guess I can wish for a visit from the Tooth Fairy too. * I make my comments as a Java veteran, and fan of the platform.

Zak 16y ago
The innovation on the Java platform is no longer in the Java language but in other languages on the platform. Both JVM-specific languages like Clojure and Scala as well as JVM implementations of existing languages like JRuby are where people go for innovation these days.
- spullara 16y ago
  I definitely agree that Clojure, Scala, Groovy, JRuby etc are pushing the platform itself forward. InvokeDynamic is in JDK7 mostly for the benefit of dynamic languages on the VM and only in JDK8 will Java language features be dependent on it.
spullara 16y ago
Personally I feel the choice was a good one. Closures (& method handles) will work out of the box with virtually every API in the JDK along with a tremendous number of APIs generated by 3rd parties. The type inference / coercion rules makes them very easy to use and possibly not as limited as you imagine. In combination with extension methods interfaces can be updated to work even more smoothly with closures and method handles without breaking libraries that provide or depend on those interfaces. I'll gladly take specific feedback on use cases that you think have been dismissed by the current proposal back to the expert group. Another question as I think they were unrelated. What kinds of features would you like to see in Java that would necessarily break backwards source compatibility? For example, I would like to see an 'auto' or 'var' keyword that is equivalent to the C++/Scala versions of same. Not a huge deal but would be nice. Thanks!

Zak 16y ago

The innovation on the Java platform is no longer in the Java language but in other languages on the platform. Both JVM-specific languages like Clojure and Scala as well as JVM implementations of existing languages like JRuby are where people go for innovation these days.

spullara 16y ago
I definitely agree that Clojure, Scala, Groovy, JRuby etc are pushing the platform itself forward. InvokeDynamic is in JDK7 mostly for the benefit of dynamic languages on the VM and only in JDK8 will Java language features be dependent on it.

spullara 16y ago

Personally I feel the choice was a good one. Closures (& method handles) will work out of the box with virtually every API in the JDK along with a tremendous number of APIs generated by 3rd parties. The type inference / coercion rules makes them very easy to use and possibly not as limited as you imagine. In combination with extension methods interfaces can be updated to work even more smoothly with closures and method handles without breaking libraries that provide or depend on those interfaces. I'll gladly take specific feedback on use cases that you think have been dismissed by the current proposal back to the expert group. Another question as I think they were unrelated. What kinds of features would you like to see in Java that would necessarily break backwards source compatibility? For example, I would like to see an 'auto' or 'var' keyword that is equivalent to the C++/Scala versions of same. Not a huge deal but would be nice. Thanks!