Java 8 Lambda binary snapshot

[markspace]

Lambda dev and the compiler group (and possibly others) published a
binary snapshot of the current state of lambdas and closures for Java.

http://jdk8.java.net/lambda/

My advice is that all Java developers should be watching this very
closely. It's pretty much the future of Java development.

I'm also looking for tutorials and other information on programing
lambdas and closures, so if anyone wants to help with that I'd
appreciate it.

Here's a couple I found:

<http://www.parleys.com/#st=5&id=2170&sl=2>

<http://www.parleys.com/#st=5&id=2632>

I also found this book at the library and it seems to be excellent:

<http://www.amazon.com/Patterns-Parallel-Programming-Timothy-Mattson/dp/0321228111>

 

[Lew]

Lambda dev and the compiler group (and possibly others) published a
binary snapshot of the current state of lambdas and closures for Java.

http://jdk8.java.net/lambda/

My advice is that all Java developers should be watching this very
closely. It's pretty much the future of Java development.

I'm also looking for tutorials and other information on programing
lambdas and closures, so if anyone wants to help with that I'd
appreciate it.

Here's a couple I found:

<http://www.parleys.com/#st=5&id=2170&sl=2>

<http://www.parleys.com/#st=5&id=2632>

I also found this book at the library and it seems to be excellent:

<http://www.amazon.com/Patterns-Parallel-Programming-Timothy-Mattson/dp/0321228111>

I look at Java closures as just syntactic sugar for anonymous interface implementations, and conversely, as anonymous interface implementations as a poor-man's closure.

This has two advantages. It keeps me out of the purist's dilemma, meaning I don't care that these aren't "real" closures. It provides a simple mental model for how to use them.

That said, it helps to be at least somewhat aware of lambda calculus and the theory and practice of "real" closures to provide a motivating mental model.

The Java perspective that closures boil down to SAM (single-abstract method) interface implementations makes it easy to reason about what they do.

 

[markspace]

I look at Java closures as just syntactic sugar for anonymous
interface implementations, and conversely, as anonymous interface
implementations as a poor-man's closure.

I think it's fortunate that Java developers aren't going to have to
absorb everything about closures and lambda expressions in one go. The
current implementation allows folks to digest the new lambda expressions
in a smaller portion size.

But yes I'd like to understand better the theory behind it too.
Especially as Brian Goetz (and probably others) seems to want to drive
parallelism into Java by using SAM literals. More information is always
good, imo.

 

[Arved Sandstrom]

I think it's fortunate that Java developers aren't going to have to
absorb everything about closures and lambda expressions in one go. The
current implementation allows folks to digest the new lambda expressions
in a smaller portion size.

But yes I'd like to understand better the theory behind it too.
Especially as Brian Goetz (and probably others) seems to want to drive
parallelism into Java by using SAM literals. More information is always
good, imo.

Truth be told I am anticipating the entire set of Java 8 features, not
just the bulk-data operations + lambdas. For what I do in real life, for
example, the modularity work will probably be more important.

I'm onside with Lew's take on these things. Also, I look at the fact
that in real life (that is to say, "on the job") it is unlikely that any
client environment I work in will be using Java 7 before Java 8 comes
out, and that it is unlikely (based on experience) that Java 8 itself
will be used by a large percentage of my clients before, say, 2015.

AHS
--
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

 

[Roedy Green]

Lambda dev and the compiler group (and possibly others) published a
binary snapshot of the current state of lambdas and closures for Java.

http://jdk8.java.net/lambda/

I was just updating the summaries for the various JDK versions, and I
realised I do know the code names for Java 8 and 9. 7 was split in
two, so it may also be called dolphin.

Anyone know?

see http://mindprod.com/jgloss/jdkreleasedates.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
Windows is a case-insensitive operating system,
but that does not mean you can forget about case.
For example, Let us assume you have a file called
Abc.txt in C:\temp, and a file called
aBc.txt in D:\temp and you type
copy C:\temp\abC.txt D:\temp. What is the name of the file in
D:\temp when you are done?
1) Abc.txt 2) aBc.txt 3) abC.txt 4) abc.txt 5) ABC.txt
Hint, the answer rhymes with the most popular word in advertising.

 

[Arne Vajhøj]

Truth be told I am anticipating the entire set of Java 8 features, not
just the bulk-data operations + lambdas. For what I do in real life, for
example, the modularity work will probably be more important.

I'm onside with Lew's take on these things. Also, I look at the fact
that in real life (that is to say, "on the job") it is unlikely that any
client environment I work in will be using Java 7 before Java 8 comes
out, and that it is unlikely (based on experience) that Java 8 itself
will be used by a large percentage of my clients before, say, 2015.

Massive rollout of a new SE version in the EE world in just 3 years
is not bad.

In another fora I heard somebody tell that this fall they were just
in the process of moving to SE 1.5 !

That is 7 years.



Arne

 

[Arne Vajhøj]

Truth be told I am anticipating the entire set of Java 8 features, not
just the bulk-data operations + lambdas. For what I do in real life, for
example, the modularity work will probably be more important.

I'm onside with Lew's take on these things. Also, I look at the fact
that in real life (that is to say, "on the job") it is unlikely that any
client environment I work in will be using Java 7 before Java 8 comes
out, and that it is unlikely (based on experience) that Java 8 itself
will be used by a large percentage of my clients before, say, 2015.

More on topic.

The fact that a SE release at Y is first widely adapted at Y+D should
not matter much.

If feature XYZ come out in 2012 instead of 2013 you will get it 1 year
earlier no matter what value of D.

I guess D could decrease over time, but I find it more likely that it
will increase over time.

Arne

 

[Lew]

Massive rollout of a new SE version in the EE world in just 3 years
is not bad.

In another fora I heard somebody tell that this fall they were just
in the process of moving to SE 1.5 !

That is 7 years.

The rule in the Java world, especially enterprise, seems to be, "If it hasn't been End-of-Lifed yet, we don't want it!"

I suppose that's one way to guarantee stability of the platform.

 

[markspace]

Lambda dev and the compiler group (and possibly others) published a
binary snapshot of the current state of lambdas and closures for Java.

http://jdk8.java.net/lambda/

One note: it seems much of the compiler is there, but that the JVM is
lagging behind and can't execute some of the compiler output. This
seems to further imply we are loosing backwards binary compatibility
with Java 8. I don't know how significant that is.

 

[Arne Vajhøj]

One note: it seems much of the compiler is there, but that the JVM is
lagging behind and can't execute some of the compiler output. This seems
to further imply we are loosing backwards binary compatibility with Java
8. I don't know how significant that is.

What??

Requiring a Java 7 java to execute Java 8 javac output is forward
compatible not backward compatible.

And AFAIK then Java has never promised or intended being
forward compatible.

Arne

 

[Arne Vajhøj]

The rule in the Java world, especially enterprise, seems to be, "If it hasn't been End-of-Lifed yet, we don't want it!"

I suppose that's one way to guarantee stability of the platform.

So true that is is not funny.

Arne

 

[markspace]

Requiring a Java 7 java to execute Java 8 javac output is forward
compatible not backward compatible.

Hmm, I guess I was thinking of "Java 8 is not backwards compatible with
Java 7 JVM," although there may be subtleties to that term that I'm not
understanding.

And AFAIK then Java has never promised or intended being
forward compatible.

My main goal was to point out to folks here who may try that snapshot
that "it's not all there yet" so they didn't spend too much time
spinning their wheels if they found something that didn't run. Likely,
it's the JDK that probably isn't 100% yet, not the coder.

 

[BGB]

Hmm, I guess I was thinking of "Java 8 is not backwards compatible with
Java 7 JVM," although there may be subtleties to that term that I'm not
understanding.

the Java 7 JVM is not forwards-compatible with Java 8 bytecode.

Java 8 would fail to be backwards compatible if it failed to run apps
compiled with the Java 7 JDK or earlier (which is not likely something
Oracle would do).

this is because the Java 7 JVM is what is running the bytecode, not the
other way around.


people put much effort into making sure old stuff keeps working, but
expecting future stuff to also work is not really a workable goal (the
best one can generally do is try to design things such that they can be
extended gracefully and breaking as little as possible in the process).

so, maybe forwards compatibility comes in a few levels (nothing formal
here, just categorization):
level 0: stuff blows up catastrophically due to the changes (in an
unpredictable way, such as the program crashing or running out of control);
level 1: the unrecognized data is rejected with an error status or message;
level 2: what is recognized is handled, but the program "gracefully
fails" regarding unrecognized data (any new features are missing, but
everything else works mostly as expected);
level 3: everything works correctly somehow.

level 1 and 2 are probably most common.

 

[Lew]

Hmm, I guess I was thinking of "Java 8 is not backwards compatible with
Java 7 JVM," although there may be subtleties to that term that I'm not
understanding.

Code emitted by a Java 5 compiler will not run on a Java 1.4 JVM (unless you specify "-target" and "-bootclasspath", and not always then). Likewise with Java 6 class files trying to run in a Java 5 JVM. Java 1.2 wouldn't run on a 1.1 JVM. It has always been thus.

Whatever you call it, the code emitted by the more advance compiler naturally cannot guarantee to run on the older platform.

My main goal was to point out to folks here who may try that snapshot
that "it's not all there yet" so they didn't spend too much time
spinning their wheels if they found something that didn't run. Likely,
it's the JDK that probably isn't 100% yet, not the coder.

Even if the JDK were "100%", it would still need a compatible JVM to run it..

Just like always.

 

[Arne Vajhøj]

Hmm, I guess I was thinking of "Java 8 is not backwards compatible with
Java 7 JVM," although there may be subtleties to that term that I'm not
understanding.


My main goal was to point out to folks here who may try that snapshot
that "it's not all there yet" so they didn't spend too much time
spinning their wheels if they found something that didn't run. Likely,
it's the JDK that probably isn't 100% yet, not the coder.

A simple example worked for me.

And it looks as if the compiler actually generates an anonymous class
similar to the traditional way.

Arne

 

[markspace]

And it looks as if the compiler actually generates an anonymous class
similar to the traditional way.

Despite posting it here I haven't got a chance to try it myself yet! Do
you mean the compiler generates anonymous classes for lambdas? Because
I thought they were using invoke-dynamic for that, which was the
incompatibility issue.

If you mean just an anonymous class that the coder declares, then yes I
doubt that will change.

 

[Roedy Green]

I look at Java closures as just syntactic sugar for anonymous interface implementations,
and conversely, as anonymous interface implementations as a poor-man's closure.

You would do the Java community a great service by posting two
snippets:

one coded the Smith Barney way with anonymous classes and another with
a rough approximation to the new closures.

 

[Arne Vajhøj]

Despite posting it here I haven't got a chance to try it myself yet! Do
you mean the compiler generates anonymous classes for lambdas? Because I
thought they were using invoke-dynamic for that, which was the
incompatibility issue.

If you mean just an anonymous class that the coder declares, then yes I
doubt that will change.

C:\Work>dir Lambda*.*
Volume in drive C is ARNEPC4
Volume Serial Number is F878-3B24

Directory of C:\Work

11/11/2011 07:50 PM 410 Lambda.java
1 File(s) 410 bytes
0 Dir(s) 939,431,432,192 bytes free

C:\Work>\sun\64bit\lambda-8-b1314-windows-x64-10_nov_2011\bin\javac
Lambda.java

C:\Work>dir Lambda*.*
Volume in drive C is ARNEPC4
Volume Serial Number is F878-3B24

Directory of C:\Work

11/13/2011 12:22 PM 678 Lambda$1.class
11/13/2011 12:22 PM 929 Lambda.class
11/11/2011 07:50 PM 410 Lambda.java
3 File(s) 2,017 bytes
0 Dir(s) 939,431,399,424 bytes free

Arne

 

[Roedy Green]

Hmm, I guess I was thinking of "Java 8 is not backwards compatible with
Java 7 JVM," although there may be subtleties to that term that I'm not
understanding.

There are two kinds of compatibility. Old programs continue to run on
new hardware or JVMs. Is that Forward or Backward compatibility? I
have heard people use both terms.

The other is new programs written carefully with new tools to avoid
using new features will run on old hardware and JVMs.

Is that Forward or Backward compatibility? or something else?

IBM salesmen loved to talk about upward and downward compatibility.
The IBM mainframers were very serious about ensuring even extremely
old code would continue to run, even if it took multiple layers of
emulation. 1410 emulation was still running in the 1990s, long after
1410 boxes lived only in museums. Again, I am not sure what they
meant by the terms. I think they used them synonyms for "good" and
"reliable".

If there is a consensus, I will do a entry in the glossary on the
matter.

 

[Arne Vajhøj]

There are two kinds of compatibility. Old programs continue to run on
new hardware or JVMs. Is that Forward or Backward compatibility? I
have heard people use both terms.

The other is new programs written carefully with new tools to avoid
using new features will run on old hardware and JVMs.

Is that Forward or Backward compatibility? or something else?

http://en.wikipedia.org/wiki/Backward_compatibility
http://en.wikipedia.org/wiki/Forward_compatibility

Arne