Java 8 Lambda binary snapshot

Discussion in 'Java' started by markspace, Nov 11, 2011.

  1. markspace

    markspace Guest

    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>
    markspace, Nov 11, 2011
    #1
    1. Advertising

  2. markspace

    Lew Guest

    markspace wrote:
    > 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.

    --
    Lew
    Lew, Nov 12, 2011
    #2
    1. Advertising

  3. markspace

    markspace Guest

    On 11/11/2011 4:20 PM, Lew wrote:
    > 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.
    markspace, Nov 12, 2011
    #3
  4. On 11-11-11 08:38 PM, markspace wrote:
    > On 11/11/2011 4:20 PM, Lew wrote:
    >> 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.
    >

    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
    Arved Sandstrom, Nov 12, 2011
    #4
  5. markspace

    Roedy Green Guest

    On Fri, 11 Nov 2011 12:55:08 -0800, markspace <-@.> wrote, quoted or
    indirectly quoted someone who said :

    >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.
    Roedy Green, Nov 12, 2011
    #5
  6. markspace

    Arne Vajhøj Guest

    On 11/12/2011 5:36 AM, Arved Sandstrom wrote:
    > On 11-11-11 08:38 PM, markspace wrote:
    >> On 11/11/2011 4:20 PM, Lew wrote:
    >>> 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.
    >>

    > 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, Nov 12, 2011
    #6
  7. markspace

    Arne Vajhøj Guest

    On 11/12/2011 5:36 AM, Arved Sandstrom wrote:
    > On 11-11-11 08:38 PM, markspace wrote:
    >> On 11/11/2011 4:20 PM, Lew wrote:
    >>> 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.
    >>

    > 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
    Arne Vajhøj, Nov 12, 2011
    #7
  8. markspace

    Lew Guest

    Arne Vajhøj wrote:
    > 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.

    --
    Lew
    Lew, Nov 12, 2011
    #8
  9. markspace

    markspace Guest

    On 11/11/2011 12:55 PM, markspace wrote:
    > 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.
    markspace, Nov 12, 2011
    #9
  10. markspace

    Arne Vajhøj Guest

    On 11/12/2011 5:02 PM, markspace wrote:
    > On 11/11/2011 12:55 PM, markspace wrote:
    >> 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.


    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, Nov 12, 2011
    #10
  11. markspace

    Arne Vajhøj Guest

    On 11/12/2011 1:07 PM, Lew wrote:
    > Arne Vajhøj wrote:
    >> 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.


    So true that is is not funny.

    Arne
    Arne Vajhøj, Nov 12, 2011
    #11
  12. markspace

    markspace Guest

    On 11/12/2011 2:09 PM, Arne Vajhøj wrote:

    > 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.
    markspace, Nov 13, 2011
    #12
  13. markspace

    BGB Guest

    On 11/12/2011 8:14 PM, markspace wrote:
    > On 11/12/2011 2:09 PM, Arne Vajhøj wrote:
    >
    >> 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.
    >


    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.


    >
    >> 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, Nov 13, 2011
    #13
  14. markspace

    Lew Guest

    markspace wrote:
    > Arne Vajhøj wrote:
    >
    >> 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.


    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.

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


    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.

    --
    Lew
    Lew, Nov 13, 2011
    #14
  15. markspace

    Arne Vajhøj Guest

    On 11/12/2011 10:14 PM, markspace wrote:
    > On 11/12/2011 2:09 PM, Arne Vajhøj wrote:
    >> 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.


    A simple example worked for me.

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

    Arne
    Arne Vajhøj, Nov 13, 2011
    #15
  16. markspace

    markspace Guest

    On 11/13/2011 7:08 AM, Arne Vajhøj wrote:

    > 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.
    markspace, Nov 13, 2011
    #16
  17. markspace

    Roedy Green Guest

    On Fri, 11 Nov 2011 16:20:03 -0800 (PST), Lew <>
    wrote, quoted or indirectly quoted someone who said :

    >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.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    I can't come to bed just yet. Somebody is wrong on the Internet.
    Roedy Green, Nov 13, 2011
    #17
  18. markspace

    Arne Vajhøj Guest

    On 11/13/2011 11:08 AM, markspace wrote:
    > On 11/13/2011 7:08 AM, Arne Vajhøj wrote:
    >
    >> 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.


    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
    Arne Vajhøj, Nov 13, 2011
    #18
  19. markspace

    Roedy Green Guest

    On Sat, 12 Nov 2011 19:14:53 -0800, markspace <-@.> wrote, quoted or
    indirectly quoted someone who said :

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

    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    I can't come to bed just yet. Somebody is wrong on the Internet.
    Roedy Green, Nov 13, 2011
    #19
  20. markspace

    Arne Vajhøj Guest

    On 11/13/2011 12:23 PM, Roedy Green wrote:
    > On Sat, 12 Nov 2011 19:14:53 -0800, markspace<-@.> wrote, quoted or
    > indirectly quoted someone who said :
    >
    >> 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?


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

    Arne
    Arne Vajhøj, Nov 13, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mickey Segal
    Replies:
    1
    Views:
    294
    Thomas Hawtin
    May 19, 2006
  2. Roman Suzi
    Replies:
    13
    Views:
    585
    Bengt Richter
    Jan 7, 2005
  3. post
    Replies:
    7
    Views:
    468
    Kenny McCormack
    Jan 14, 2008
  4. Steve Dogers

    lambda vs non-lambda proc

    Steve Dogers, Mar 30, 2009, in forum: Ruby
    Replies:
    1
    Views:
    153
    Sean O'Halpin
    Mar 30, 2009
  5. Haochen Xie
    Replies:
    4
    Views:
    228
    Haochen Xie
    Mar 17, 2013
Loading...

Share This Page