Java SE 8 Proposed Final Draft Specification — Draft 1
cr.openjdk.java.net
cr.openjdk.java.net
My colleague's reference for developer-facing changes in Java 8: http://www.techempower.com/blog/2013/03/26/everything-about-...
Kudos to whoever wrote it up!
[1] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-March...
That's how I read it at least.
So what's the point of describing the on a page talking about additions to Java 8?
https://github.com/orfjackal/retrolambda
"Retrolambda lets you run Java 8 code with lambda expressions on Java 7 or lower. It does this by transforming your Java 8 compiled bytecode so that it can run on a Java 7 runtime. After the transformation they are just a bunch of normal .class files, without adding any runtime dependencies."
Another issue is the depth of the process on each change: there are a number of discussions on each feature with multiple proposals to determine the best way to implement any feature and how it will fit in, etc. The number of companies and people involved in the feature design and implementation in each change is generally an order of magnitude greater than those other languages.
Comes down to heavy bureaucracy and design by committee creating a very long process - but the end result is generally extremely well thought through and tested, so I'm personally not complaining since I'm not footing the bill.
Have you looked at the API of function types? If we needed a definition of incoherent, overcomplicated, painfully stupid non-sense, this would be it.
I'd say the issue with Oracle's style of development is that it is primarily time-driven which just doesn't work for evolving languages.
Features are not developed and shipped when they are ready. Instead, they decide that they want to ship X in the upcoming version Y and sacrifice the quality to reach the dead-line.
Of course, stuff is ugly and inconsistent if it has been rushed all the time.
That the persons involved in designing those features are completely under-qualified doesn't help either.
Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true.
I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/pa...
The amount of times they managed to back themselves into a corner is just horrifying.
> Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true.
And to Java 9. Any actual improvement would assume that a considerable amount of people would have kept working on those things in the meantime. First delaying the feature and then reallocating the people to extinguish fires somewhere else (security, applets, ...) doesn't help.
Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway. Let's at least hope that they documented the experience they gained, so that they don't repeat all the mistakes again.
I'm not sure you understand what you're looking at. Defining a "function type" in Java 8 looks like this:
interface MyFunctionType {
double f(String x, Runnable y, int z);
}
interface MyFunctionType {
double foo(String a, Runnable b, int c);
}
> Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway.
I'm not sure how much is "lost", but 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. And when a language is used by millions of developers and with trillions lines of existing code, there is a lot to consider, because a lot is at stake.
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.
How is this in any way disagreeing with what I said? Did you actually look at Doug Lea's reasoning back then? I don't think he would defend any of his claims today. Back then, the issues caused by not having function types just weren't anticipated. This would be obvious if one followed the appropriate mailing lists where this was discussed in depth.
> 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.
Beating down your own straw men seems to be your hobby, I guess?
> 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.
No, they were just betting the house that the JVM engineers would save their asses, but as we know that didn't work out so well. They didn't really have a plan B, so they started to manually duplicate code for some primitive types.
> Again, the idea is always do the least "powerful" thing possible that will give you the most benefit.
This hasn't worked out at all and is one of the reasons why Java is incredibly hard to evolve. One just can't keep piling half-assed ideas on top of each other forever.
Anyway, I'm not sure why you are so defensive. Yes, Java will ship with some kind of lambdas, but they will be inferior to pretty much anything out there in terms of usability, readability, maintainability, performance and will be a major pain point when evolving the language in the future.
Why not just accept it and move on?
Because it's not true. I don't know if you've seen the lambda performance benchmarks but they're pretty darn good. I don't know what you mean by "usability" but some uses of lambdas in other languages are not a right fit for the Java philosophy. When it comes to maintainability, lambdas are great. Method handles don't enforce any particular implementation strategy, and the current language does not even preclude introducing function types in the future if it proves to be as big a pain point as you claim; OTOH, introducing function types now would have made it pretty much impossible to go back.
Now, let me be clear: I am not saying Java is the best language out there (I don't think such a thing exists). I am not even saying it's the best language for the specific goals it took upon itself. All I'm saying is that given its unbelievably huge adoption, backwards compatibility and philosophy, its maintainers are doing a pretty good job.
Nonsense. Just because you throw out a design doesn't mean that "everything is lost": you've learned a lot in the process and you're going to use that knowledge to draft the next design.
Java is often made fun of for moving at a glacial pace but quite a few languages could learn a thing or two about the benefits of shipping features that are designed right from v1 (Scala has been much more reckless in that area).
... which is exactly what I said in the next sentence, right? :-)
> but quite a few languages could learn a thing or two about the benefits of shipping features that are designed right from v1
Eh, could you mention a few things which were "designed right from v1"? I can only imagine enums, but what else?
A lot of thought has been put into that, and I think the result is both elegant and at the same time integrates beautifully with legacy code. Perhaps most importantly, a lot of existing libraries will automatically support lambdas naturally without them ever being designed for lambdas and without recompilation.
Java's lambdas have been anything but rushed. They were debated long and hard (for literally years), and different approaches were considered, tried and discarded before the present spec was accepted. Here's a summary of the discussion from 2007: http://blog.joda.org/2007/12/closures-comparing-core-of-bgga...
In the end, the "BGGA" proposal for full function types in Java was rejected in favor of something similar to the Doug Lea-Josh Bloch-Bob Lee proposal. Bob Lee summarized his perspective so[1]: "Loosely speaking, simple syntax sugar for anonymous inner classes buys Java 90% of the power of BGGA closures while carrying only 10% of the weight. We think it's the "knee in curve" where we get the most bang for our buck." This is perfectly in line with the Java philosophy. Other languages may prefer getting 100% of the power for ten times the cost, which might make sense if your requirements and use cases are different.
In the end, though, Lambda's are more powerful than the original "concise syntax for anonymous classes" because method handles are used as the bytecode-level description of lambdas, while anonymous classes are an implementation detail that can be changed later without affecting binary compatibility.
This talk by Joshua Bloch, discusses "the closures controversy" in some depth: http://parleys.com/play/514892250364bc17fc56bb15/chapter0/ab.... He explains that PL research was a declared "non-goal" for Java, which was meant to be kept simple. "Nice" features were rejected by design, with the goal of only including those that solve problems that really hurt.
P.S.
The lambda discussions predate the Oracle acquisition. Also, I wouldn't call Gilad Bracha, Joshua Bloch and Guy Steele underqualifed.
[1]: http://blog.crazybob.org/2006/10/java-closure-spectrum.html
Obviously, at this stage Java has accumulated quite a lot of baggage, as could be expected from such a mature and ubiquitous language. Some of these issues are addressed in Java 8, and some by other JVM languages with various degrees of adherence to the Java philosophy.
I would strongly recommend watching these two talks by Joshua Bloch, where he explains Java's goals, philosophy and design. These goals were later adopted by Google for their own new languages, Dart and Go, that have the same "Java feel":
* http://parleys.com/play/514892250364bc17fc56bb15/chapter11/a...
* http://parleys.com/play/514892290364bc17fc56c444/chapter0/ab...
This isn't to say Anders and company didn't significantly improve it, to be clear, but I tend to think they were looking much more at Java than at Object Pascal.
tl;dr - I think we mostly agree.
Edit: look at the code.
And as for backward compatibility, they already did. I love the myth that java never broke backwards compatibility. Bytecode maybe (), they definitely broke syntax compatiblity.
: The various xml parsers and other library thrash really do break backwards bytecode compatiblity.
Proof?
Here's a couple of recent examples the Guava authors have fixed. Fortunately they were in internals and not their public API, so users won't care.
https://code.google.com/p/guava-libraries/source/detail?r=7d... https://code.google.com/p/guava-libraries/source/detail?r=25...
What is meant by "breaking backward compatibility" is when the grammar is altered in a way that makes existing sources no longer compile.
In case it's the former, "a lot nicer" is subjective, so it carries no weight in the discussion.
If the latter... well, go read a few books on compiler design and language theory.
You do know D the language was written by compiler expert, right - if you had a point or just insult.
Java has a reputation of a bad community, and you just underline it here.