Java 8 Lambda binary snapshot

A

Arne Vajhøj

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.

Anonymous class:

ArrayList<String> lst = new ArrayList<String>();
lst.add("A");
lst.add("BB");
lst.add("CCC");
Collections.sort(lst, new Comparator<String>() {
public int compare(String s1, String s2) {
return -s1.compareTo(s2);
}
});
for(String s : lst) {
System.out.println(s);
}

Java 8 lambda:

import java.util.ArrayList;
import java.util.Collections;

public class Lambda {
public static void main(String[] args) {
ArrayList<String> lst = new ArrayList<String>();
lst.add("A");
lst.add("BB");
lst.add("CCC");
Collections.sort(lst, (s1,s2)-> -s1.compareTo(s2));
for(String s : lst) {
System.out.println(s);
}
}
}

Arne
 
L

Lew

Roedy said:
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.

Backward compatibility is when the new platform runs old code, just as those serious IBM mainframers promised. In other words, it's when the Java 8 platform runs Java 7- code. Forward compatibility is when new code runs on the old platform, just as neither IBM nor Java have ever promised. Never.

The complaint was that Java 8 code doesn't run under Java 7. That's forward compatibility. Java 7 doesn't run under 6, 6 doesn't run under 5, 5 doesn't run under 1.4, just try running code with an 'assert' under Java 1.3, forget about using 'ArrayList' in Java 1.1!

Ooh, surprise! New features don't run on old engines! File a bug!

It's never been different.
 
A

Andreas Leitgeb

Arne Vajhøj said:
public int compare(String s1, String s2) {
return -s1.compareTo(s2);
}

I'd use s2.compareTo(s1) instead, to prevent the problem
of -Integer.MIN_VALUE < 0
Collections.sort(lst, (s1,s2)-> -s1.compareTo(s2));

Really? Without specifying types for s1 and s2? Looking forward to it...
 
A

Arne Vajhøj

Arne Vajhøj said:
Collections.sort(lst, (s1,s2)-> s2.compareTo(s1)); [mod]
Really? Yes.

Cool!
Looking forward to it...
You can download the early access kit now and play with it.

Wouldn't help me for my current projects, though... :-(

No - you will need to wait minimum 1-2 years - longer if
it is one of those cases where upgrades are considered
as fun as getting teeth pulled out at the dentist.

Arne
 
A

Arved Sandstrom

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
 
N

Nasser M. Abbasi

Java 8 lambda:

import java.util.ArrayList;
import java.util.Collections;

public class Lambda {
public static void main(String[] args) {
ArrayList<String> lst = new ArrayList<String>();
lst.add("A");
lst.add("BB");
lst.add("CCC");
Collections.sort(lst, (s1,s2)-> -s1.compareTo(s2));
for(String s : lst) {
System.out.println(s);
}
}
}

Arne

ps. I just heard about this Lambda thing ;)

This looks like the ability to have, what is called in Mathematica,
or may be other functional languages, a pure function, that one
can define and use on the fly ?

For example, in Mathematica, one can write

"Sort[list,p]
sorts using the ordering function p. "

and is coded like this, for example:

In[11]:= Sort[{4,1,3,2,2},#1>#2&]
Out[11]= {4,3,2,2,1}

where the '&' indicates the end of the function, and
#1 means first argument, and #2 mean the second argument.

One can also write the pure function more explicit, like this:

In[8]:= Sort[{4,1,3,2,2},Function[{x,y},x<y]]
Out[8]= {1,2,2,3,4}

Is this, somewhat, close to what Lambda in Java allows?

It is very useful feature to be able to do this sort of thing.
(I need to read more about Java 8, sounds interesting)

--Nasser
 
L

Lew

Arved said:
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.
 
L

Lew

Nasser said:
ps. I just heard about this Lambda thing ;)

"This Lambda [sic] thing" has been around longer than the Java language.
This looks like the ability to have, what is called in Mathematica,
or may be other functional languages, a pure function, that one
can define and use on the fly ?

For example, in Mathematica, one can write

"Sort[list,p]
sorts using the ordering function p. "

and is coded like this, for example:

In[11]:= Sort[{4,1,3,2,2},#1>#2&]
Out[11]= {4,3,2,2,1}

where the '&' indicates the end of the function, and
#1 means first argument, and #2 mean the second argument.

This has existed in Java since about version 1.1, only the syntax is rather more verbose.

They don't call it "pure function" in Java; there is no such thing. It's called "implementation of a callback interface" in Java.

The "lambda" feature of Java 8 is a syntactic sweetener of the interface-implementation idiom, not the addition of "pure" (whatever that means) functions.
One can also write the pure function more explicit, like this:

In[8]:= Sort[{4,1,3,2,2},Function[{x,y},x<y]]
Out[8]= {1,2,2,3,4}

Is this, somewhat, close to what Lambda in Java allows?

Why not read the literature, cited at the top of this thread? That question was answered from the very start of this conversation. Of course, it does require that you actually click to and read the information.

OTOH, documentation is a wonderful thing, and the habit of studying it a most empowering one.

Try it, why don't you?
It is very useful feature to be able to do this sort of thing.
(I need to read more about Java 8, sounds interesting)

Yes - yes you do.
 
R

Robert Klemme

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
 
A

Arne Vajhøj

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
 
L

Lew

Arne said:
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 aweek 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 ona sessile platform is the wise choice.
 
B

BGB

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

Nasser M. Abbasi

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
 
B

BGB

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

Lew

BGB said:
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?
 
A

Arne Vajhøj

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
 
B

BGB

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

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top