Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9856 > unrolled thread

Java 8 Lambda binary snapshot

Back to article view | Back to comp.lang.java.programmer

Contents

  Java 8 Lambda binary snapshot markspace <-@.> - 2011-11-11 12:55 -0800
    Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-11 16:20 -0800
      Re: Java 8 Lambda binary snapshot markspace <-@.> - 2011-11-11 16:38 -0800
        Re: Java 8 Lambda binary snapshot Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-12 06:36 -0400
          Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 09:19 -0500
            Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-12 10:07 -0800
              Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 17:09 -0500
              Re: Java 8 Lambda binary snapshot Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-14 06:25 -0400
                Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-14 06:45 -0800
                  Re: Java 8 Lambda binary snapshot Robert Klemme <shortcutter@googlemail.com> - 2011-11-14 23:28 +0100
                  Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-15 20:34 -0500
                    Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-15 22:28 -0800
                      Re: Java 8 Lambda binary snapshot BGB <cr88192@hotmail.com> - 2011-11-16 07:43 -0700
                        Re: Java 8 Lambda binary snapshot kensi <kensi_kensington@zoonoses.de> - 2011-11-16 12:53 -0500
                          Re: Java 8 Lambda binary snapshot "Nasser M. Abbasi" <nma@12000.org> - 2011-11-16 12:20 -0600
                            Re: Java 8 Lambda binary snapshot BGB <cr88192@hotmail.com> - 2011-11-16 14:27 -0700
                              Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-16 14:04 -0800
                                Re: Java 8 Lambda binary snapshot BGB <cr88192@hotmail.com> - 2011-11-17 10:05 -0700
                      Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-16 18:57 -0500
          Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 09:23 -0500
      Re: Java 8 Lambda binary snapshot Roedy Green <see_website@mindprod.com.invalid> - 2011-11-13 09:12 -0800
        Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-13 12:39 -0500
          Re: Java 8 Lambda binary snapshot Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 20:13 +0000
            Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-13 15:43 -0500
              Re: Java 8 Lambda binary snapshot Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 21:06 +0000
                Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-13 16:16 -0500
          Re: Java 8 Lambda binary snapshot "Nasser M. Abbasi" <nma@12000.org> - 2011-11-14 08:03 -0600
            Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-14 06:51 -0800
    Re: Java 8 Lambda binary snapshot Roedy Green <see_website@mindprod.com.invalid> - 2011-11-12 04:53 -0800
    Re: Java 8 Lambda binary snapshot markspace <-@.> - 2011-11-12 14:02 -0800
      Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 17:09 -0500
        Re: Java 8 Lambda binary snapshot markspace <-@.> - 2011-11-12 19:14 -0800
          Re: Java 8 Lambda binary snapshot BGB <cr88192@hotmail.com> - 2011-11-12 20:56 -0700
          Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-13 05:08 -0800
          Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-13 10:08 -0500
            Re: Java 8 Lambda binary snapshot markspace <-@.> - 2011-11-13 08:08 -0800
              Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-13 12:23 -0500
          Re: Java 8 Lambda binary snapshot Roedy Green <see_website@mindprod.com.invalid> - 2011-11-13 09:23 -0800
            Re: Java 8 Lambda binary snapshot Arne Vajhøj <arne@vajhoej.dk> - 2011-11-13 12:27 -0500
            Re: Java 8 Lambda binary snapshot Lew <lewbloch@gmail.com> - 2011-11-13 11:08 -0800

Page 1 of 2  [1] 2  Next page →

#9856 — Java 8 Lambda binary snapshot

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>

[toc] | [next] | [standalone]

#9862

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

[toc] | [prev] | [next] | [standalone]

#9863

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.

[toc] | [prev] | [next] | [standalone]

#9868

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

[toc] | [prev] | [next] | [standalone]

#9878

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

[toc] | [prev] | [next] | [standalone]

#9883

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

[toc] | [prev] | [next] | [standalone]

#9886

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

[toc] | [prev] | [next] | [standalone]

#9951

On 11-11-12 02: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.
> 
One of my current projects (lasting into next year) is to help out a
client with conversion of some apps from J2EE 1.4 to Java EE 5. I
consider this a small victory actually. :-)

What actually holds us back with adoption of recent Java (JDK/JRE)
versions is not any particular reluctance on the part of most clients to
keep up with the Joneses in that respect, but because they are very
conservative with all their major software (like app servers)...which if
it's not certified for a later Java means we can't move to it.

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

[toc] | [prev] | [next] | [standalone]

#9955

Arved Sandstrom wrote:
> What actually holds us back with adoption of recent Java (JDK/JRE)
> versions is not any particular reluctance on the part of most clients to
> keep up with the Joneses in that respect, but because they are very
> conservative with all their major software (like app servers)...which if
> it's not certified for a later Java means we can't move to it.

That's just the same phenomenon - "not certified for a later Java" means that someone was unwilling to move to that later Java until it was EOLed.

Why don't the vendors certify for the later Java in anything less than five years?

It's the same question.  Pushing it back one level doesn't answer it.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9961

On 14.11.2011 15:45, Lew wrote:
> Arved Sandstrom wrote:
>> What actually holds us back with adoption of recent Java (JDK/JRE)
>> versions is not any particular reluctance on the part of most
>> clients to keep up with the Joneses in that respect, but because
>> they are very conservative with all their major software (like app
>> servers)...which if it's not certified for a later Java means we
>> can't move to it.
>
> That's just the same phenomenon - "not certified for a later Java"
> means that someone was unwilling to move to that later Java until it
> was EOLed.
>
> Why don't the vendors certify for the later Java in anything less
> than five years?
>
> It's the same question.  Pushing it back one level doesn't answer
> it.

One reason might be the partial failure of the promise of GC.  What I 
mean is this: when introduced to GC the usual message is that it is 
better than manual memory management and with it software will be more 
robust (i.e. not throwing cores, some may even claim that there are no 
memory leaks) by having the JVM decide when to collect which garbage. 
Also, developers will be more productive etc.  This works remarkably 
well in a number of situations.

However, the enterprise world often has more demanding requirements 
(such as dealing with large memory *and* low latency at the same time). 
  Whoever went through the exercise of tuning GC settings (of which 
there are plenty - just execute [1] on your favorite JVM) for such an 
application will be very reluctant to switch to a new Java version (or 
other garbage collector for that matter).  If you have found a set of 
settings with which your application works reliably as expected then you 
are not easily giving it up because the cost to go through the testing, 
measuring etc. with a new JVM can be significant.

Kind regards

	robert

[1] Find out all the options:
$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#9968

On 11/14/2011 9:45 AM, Lew wrote:
> Arved Sandstrom wrote:
>> What actually holds us back with adoption of recent Java (JDK/JRE)
>> versions is not any particular reluctance on the part of most clients to
>> keep up with the Joneses in that respect, but because they are very
>> conservative with all their major software (like app servers)...which if
>> it's not certified for a later Java means we can't move to it.
>
> That's just the same phenomenon - "not certified for a later Java" means that someone was unwilling to move to that later Java until it was EOLed.
>
> Why don't the vendors certify for the later Java in anything less than five years?
>
> It's the same question.  Pushing it back one level doesn't answer it.

Usually app server versions and specific JVM versions are tied.

It is even in the specs.

Java EE 6 spec:

This specification requires that containers provide a Java Compatible™ 
runtime environment, as defined by the Java Platform, Standard Edition, 
v6 specification (Java SE).

Java EE 5 spec:

This specification requires that containers provide a Java Compatible™ 
runtime environment, as defined by the Java 2 Platform, Standard 
Edition, v5.0 specification (J2SE).

J2EE 1.4 spec:

This specification requires that containers provide a Java Compatible™ 
runtime
environment, as defined by the Java 2 Platform, Standard Edition, v1.4 
specification
(J2SE).

J2EE 1.3 spec:

This specification requires that containers provide a Java Compatible™ 
runtime
environment, as defined by the Java 2 Platform, Standard Edition, v1.3 
specification
(J2SE).

Arne

[toc] | [prev] | [next] | [standalone]

#9970

Arne Vajhøj wrote:
> Lew wrote:
>> Why don't the vendors certify for the later Java in anything less than five years?
>>
>> It's the same question.  Pushing it back one level doesn't answer it.
> 
> Usually app server versions and specific JVM versions are tied.
> 
> It is even in the specs.
> 
> Java EE 6 spec:
> 
> This specification requires that containers provide a Java Compatible™ 
> runtime environment, as defined by the Java Platform, Standard Edition, 
> v6 specification (Java SE).
> ...

And?

That says nothing about the vendors or why they lag the specs for so long.  It is a summary of the specs that they might lag.

Mind you, I don't think it's a bad thing to be conservative in platform migration.  I've worked in Enterprise Java for a fair bit and it's no small thing for, say, a government agency that processes 100 million documents in a week to change platforms.  My earlier comment about EOL as a guarantee of stability is not entirely a joke, and certainly not the fictional kind.

It's also no mean feat to implement a Java EE spec in a way that lets such an application work successfully.

All of which raises the question as to why there needs to be an upgraded Java version in the first place.  Maybe the right thing to do is to let a language specification stagnate, at least for rather longer than programmers are used to imagining.  Maybe basing large-scale mission-critical systems on a sessile platform is the wise choice.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9975

On 11/15/2011 11:28 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Why don't the vendors certify for the later Java in anything less than five years?
>>>
>>> It's the same question.  Pushing it back one level doesn't answer it.
>>
>> Usually app server versions and specific JVM versions are tied.
>>
>> It is even in the specs.
>>
>> Java EE 6 spec:
>>
>> This specification requires that containers provide a Java Compatible™
>> runtime environment, as defined by the Java Platform, Standard Edition,
>> v6 specification (Java SE).
>> ...
>
> And?
>
> That says nothing about the vendors or why they lag the specs for so long.  It is a summary of the specs that they might lag.
>
> Mind you, I don't think it's a bad thing to be conservative in platform migration.  I've worked in Enterprise Java for a fair bit and it's no small thing for, say, a government agency that processes 100 million documents in a week to change platforms.  My earlier comment about EOL as a guarantee of stability is not entirely a joke, and certainly not the fictional kind.
>
> It's also no mean feat to implement a Java EE spec in a way that lets such an application work successfully.
>
> All of which raises the question as to why there needs to be an upgraded Java version in the first place.  Maybe the right thing to do is to let a language specification stagnate, at least for rather longer than programmers are used to imagining.  Maybe basing large-scale mission-critical systems on a sessile platform is the wise choice.
>

yeah, different areas have different requirements...

enterprise systems want a very stable platform that hardly ever changes 
(sort of like IBM mainframes...).

more average programmers want something which is reasonably fast and 
reasonably stable, and adds new features here-and-there to keep them 
interested.


and, people who want scripting languages mostly want lots of features 
and for everything to be doable with a minimum of effort, but largely 
forsake both performance and reliability in doing so (typically, any 
parts which need to be stable or reliable are written in C or C++ or 
similar in these contexts, where C++ also adds lots of features, but its 
current complexity is terrible...).

sadly, my scripting language/VM has also been somewhat tending towards 
internal complexity as well (partly as evidenced by a 617 kloc VM, and 
approx 400 opcodes in the present bytecode, albeit a few holes bump the 
current max opcode number up to 540).

some of this complexity might be due to trying to be both very dynamic 
(like JavaScript, on which the language is based), and at the same time 
work fairly close to 1:1 with C code and data. some also due to 
interpreter design shift as well.


or such...

[toc] | [prev] | [next] | [standalone]

#9979

On 16/11/2011 9:43 AM, BGB wrote:
> typically, any parts which need to be stable or reliable are written in
> C or C++

The horror, the horror ...

[toc] | [prev] | [next] | [standalone]

#9980

On 11/16/2011 11:53 AM, kensi wrote:
> On 16/11/2011 9:43 AM, BGB wrote:
>> typically, any parts which need to be stable or reliable are written in
>> C or C++
>

> The horror, the horror ...

When I see 'C and C++' next to 'stable and reliable', I simply took it as
being a joke and BGB here just forgot to add the smiley face somewhere?

--Nasser

[toc] | [prev] | [next] | [standalone]

#9982

On 11/16/2011 11:20 AM, Nasser M. Abbasi wrote:
> On 11/16/2011 11:53 AM, kensi wrote:
>> On 16/11/2011 9:43 AM, BGB wrote:
>>> typically, any parts which need to be stable or reliable are written in
>>> C or C++
>>
>
>> The horror, the horror ...
>
> When I see 'C and C++' next to 'stable and reliable', I simply took it as
> being a joke and BGB here just forgot to add the smiley face somewhere?
>

there are worse options...

one could try to write "mission critical" software in Python or VBScript 
or similar...

but, in general, the stability or reliability of C or C++ isn't all that 
bad, as once one has everything working correctly, it will generally 
keep on working.

vs Java?... well, one can make an argument (there are pros and cons 
here...).


generally, C is more stable than my own BGBScript language though, 
nevermind C being much faster... it is a feature-filled language, but 
performance and reliability are not exactly its strong areas... partial 
issues due to an unreliable (conservative) GC and lingering hidden 
compiler/interpreter/runtime/... bugs.


or such...

[toc] | [prev] | [next] | [standalone]

#9985

BGB wrote:
> generally, C is more stable than my own BGBScript language though, 

I'm sure that's fascinating for all those BGBScript users out there.

How does this cast insight into Java programming again?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10005

On 11/16/2011 3:04 PM, Lew wrote:
> BGB wrote:
>> generally, C is more stable than my own BGBScript language though,
>
> I'm sure that's fascinating for all those BGBScript users out there.
>
> How does this cast insight into Java programming again?
>

because the statement they were poking at was in the context of C as 
more reliable than BGBScript, not as more reliable than Java.

granted, me and sticking on any particular topic is not a strong area...

[toc] | [prev] | [next] | [standalone]

#9987

On 11/16/2011 1:28 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Why don't the vendors certify for the later Java in anything less than five years?
>>>
>>> It's the same question.  Pushing it back one level doesn't answer it.
>>
>> Usually app server versions and specific JVM versions are tied.
>>
>> It is even in the specs.
>>
>> Java EE 6 spec:
>>
>> This specification requires that containers provide a Java Compatible™
>> runtime environment, as defined by the Java Platform, Standard Edition,
>> v6 specification (Java SE).
>> ...
>
> And?
>
> That says nothing about the vendors or why they lag the specs for so
> long. It is a summary of the specs that they might lag.

The vendors release new versions of the app server that works
with new EE or SE versions.

But they don't certify a given app server version for new SE versions.

And the specs support that policy.

Arne

[toc] | [prev] | [next] | [standalone]

#9879

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web