| > I'm not sure you understand what you're looking at. Yes, I do. The issue is that their ideas of lambdas work exactly in those cases where using a lambda is just a nice replacement for existing AICs. With that reasoning they thought that they could get away without standard function types. But then, they added their "bulk operations" to collections and started to realize they were in trouble, because there didn't exist any SAM types they could use _and_ coming up with names for anonymous function literals was kind of idiotic. But with function types already ruled out and time running short, they decided to make up ad-hoc function types. A bit later, they also realized that all the boxing had a non-negligible impact on performance, so they started to add _some_ ad-hoc specializations to the already ad-hoc function types, but of course not _all_ of them. Not even mentioning that the naming is just completely out of whack. At the same time, they started to ask people what use-cases they could think of for real Generics in Java 9. One could argue that it's a case of the left hand not knowing what the right hand does at Oracle ... but it was in fact the _same_ person who OK'ed the broken function type design in the first place who was now asking for feedback. So in the best case, a considerable amount of types in java.util.function (did I already mention that the name is just FUBAR?) will be obsolete in the version right after Java 8 and in the worst case, those types will serve as ammunition against fixing Generics for good. This is a good case of making every imaginable error in language design one can think of. > most Java users specifically said, in this case and in others, that they prefer postponing a feature until its been done "right" after die consideration Yeah. I think no one will ever argue against that. You are not making up straw men again, aren't you? What people criticize is that what Oracle claims is not consistent with their actions. If you want to sell people the idea of delaying a feature to "get it right", for gods sake, please actually make sure you "got it right" when shipping it versions later. |
This is simply not true. Doug Lea, the author of java.util.concurrent, and of ForkJoin in particular, was one of the main driving forces behind lambdas; he requested them about 7 years ago precisely for those bulk operations. The same Doug Lea rejected function types way back then in favor of CICE.
Already back in 2007-2008 it became clear that function types are a bad fit for Java. Java's designers explicitly mentioned currying, general functional-style programming, and user-defined control structures as things they wanted to avoid. These things may very well have a place in other programming languages, but not in Java. If you don't want a blue-collar programming language then Java is simply not meant for you. Java, like Clojure or Haskell, has a very specific flavor. A feature can be right for one language but not for another.
> A bit later, they also realized that all the boxing had a non-negligible impact on performance, so they started to add _some_ ad-hoc specializations to the already ad-hoc function types, but of course not _all_ of them. Not even mentioning that the naming is just completely out of whack.
Again, not true. Java's designers are extremely focused on performance, and did not "realize" all of a sudden boxing has a non-negligible impact on performance. Also, those are not "ad hoc" specializations. All they did was pre-define some small subset of possible function types that they figured will be widely used. Again, the idea is always do the least "powerful" thing possible that will give you the most benefit.