
Java SE 8 Proposed Final Draft Specification — Draft 1 - Eduard
http://cr.openjdk.java.net/~mr/se/8/java-se-8-pfd-spec-01/
======
bhauer
Looking forward to it! We've been experimenting with early builds and the
improvements are enjoyable.

My colleague's reference for developer-facing changes in Java 8:
[http://www.techempower.com/blog/2013/03/26/everything-
about-...](http://www.techempower.com/blog/2013/03/26/everything-about-
java-8/)

~~~
krzyk
Unfortunately the link you provided discusses lambdas but then after I'm
hooked into them it says : "They were considered for Java 8 but were not
included, for simplicity and due to time constraints."

So what's the point of describing the on a page talking about additions to
Java 8?

~~~
benjiweber
The author is referring to the additional lambda-related features below (Non-
final variable capture, Exception transparency, Control Flow). Lambdas most
certainly are included in 8.

------
huherto
If I understand correctly it will by ready for production by 2013-03-18

[http://openjdk.java.net/projects/jdk8/milestones](http://openjdk.java.net/projects/jdk8/milestones)

~~~
kumarm
This Page has more accurate dates:
[http://openjdk.java.net/projects/jdk8/](http://openjdk.java.net/projects/jdk8/)

------
hrjet
Btw, if you want Lambdas _now_ , you can try this project:

[https://github.com/orfjackal/retrolambda](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."

------
kvtrew76557
Still quite far behind what is provided by C# and Scala, among others. At
least it's a step in the right direction. These are the first major language
changes to Java in nearly a decade, say what you like about Oracle, but at
least they have the funds to develop Java whereas Sun was running on empty.

~~~
SwellJoe
And, yet, one of the languages you've mentioned (Scala), and many other
languages that have moved faster than Java (most of the ones in common usage
today, in fact) have far smaller budgets than even Sun was able to throw at
Java. Does it really take such a large budget to improve Java? Why does it
take so much larger a budget than, say, Go or Haskell or Python or Scala?

~~~
RyanZAG
Java is very heavily set on backwards compatibility - no new feature is
allowed to affect existing code and any new features must fit into the
existing features. This is different to Python for example where they had
backwards incompatible changes in v3.

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.

~~~
frowaway001
> but the end result is generally extremely well thought through and tested

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.

~~~
RyanZAG
Only briefly - it looks pretty straight forward. Could you explain what's
wrong with it?

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.

~~~
frowaway001
> Only briefly - it looks pretty straight forward. Could you explain what's
> wrong with it?

I think this link says it all:
[http://download.java.net/jdk8/docs/api/java/util/function/pa...](http://download.java.net/jdk8/docs/api/java/util/function/package-
summary.html)

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.

~~~
pron
> I think this link says it all:
> [http://download.java.net/jdk8/docs/api/java/util/function/pa...](http://download.java.net/jdk8/docs/api/java/util/function/pa..).

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);
      }
    

That package merely defines some common types. They are all interchangeable,
by the way, so if your method takes a parameter of type "YourFunctionType",
defined so:

    
    
      interface MyFunctionType {
        double foo(String a, Runnable b, int c);
      }
    

Then the same lambda expression could represent both MyFunctionType and
YourFunctionType. You don't need to use the types defined in that package, you
don't need to remember what they're called etc.

> 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.

~~~
frowaway001
> 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.

~~~
pron
> 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.

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.

~~~
frowaway001
> 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.

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?

~~~
pron
> 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.

------
jhawk28
It wouldn't be a new version of Java if it didn't have a new Time API.

------
mess
Can we expect any improvement in startup time so that it becomes a little bit
more suitable for command line tools?

~~~
melling
Java 9. Project Jigsaw. Here's a blog from 2008 that discusses it.

[https://blogs.oracle.com/mr/entry/jigsaw](https://blogs.oracle.com/mr/entry/jigsaw)

------
goggles99
HAHA, C# copied Java in many ways, now Java is following suit. Good for them.

~~~
jpitz
What, it copied a single-class, multiple-interface statically typed OO
language? Since the lead architect on C# designed one of those that predated
Java, I think it is pretty clear what he was copying.

[http://en.wikipedia.org/wiki/Object_Pascal](http://en.wikipedia.org/wiki/Object_Pascal)

~~~
eropple
I think this is a little bit handwavey regarding the historical background. My
understanding is that NGWS, and then .NET 1.0, grew out of J++ and the
Microsoft JVM extensions being a problem. Most of C#'s semantics, especially
with regards to C# 1.0, very closely parallel Java's (right down to stuff like
missing generics in the first release), as does large parts of the .NET class
library. I don't think it's unfair to characterize it as C# taking a _lot_ of
notes from Java, nor do I think it's unfair to characterize Java doing the
same thing here.

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.

~~~
jpitz
I don't think it's unfair to say C# took some cues from Java either, but
Property syntax, for example, (sadly) has no counterpart in Java, only Object
Pascal/Delphi. Historically, the impetus behind C#'s birth _absolutely_ was
Java and the J++ debacle.

tl;dr - I think we mostly agree.

------
puppetmaster3
Lol, Java. This is what v8 should have been:
[http://vibed.org](http://vibed.org)

Edit: look at the code.

~~~
laureny
A language should have been an asynchronous library? How does that even make
sense?

~~~
puppetmaster3
Look at the code, Java like, no? But a lot nicer.

~~~
aeonsky
So you want Oracle to include a "shared" and "auto" keywords and break
millions of programs?

~~~
grogenaut
Yes, Yes I do.

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.

~~~
laureny
> I love the myth that java never broke backwards compatibility. Bytecode
> maybe (), they definitely broke syntax compatiblity.

Proof?

~~~
mhixson
If by "syntax compatibility" he means code that compiles in one version does
not compile is another, that's definitely true. Name collisions with the new
default methods in Java 8 are one source. If your Comparator-implementing
class has a method "void reverseOrder()", that will no longer compile.

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=7de3cbca3854ae0d9e9f7973a8f3cfe855a2407a)
[https://code.google.com/p/guava-
libraries/source/detail?r=25...](https://code.google.com/p/guava-
libraries/source/detail?r=257148b2901c8b8ec1b06d9c10804300ac3d06d0)

~~~
laureny
This happens for all languages and is not usually considered as "a language
breaking backward compatibility", it's purely a library concern.

What is meant by "breaking backward compatibility" is when the grammar is
altered in a way that makes existing sources no longer compile.

