The Details of Oracle's JDK 7 and 8 'Plan B'

gkunene writes "Oracle has put Java 7 and 8 features up for Java Community approval, providing a clear indication of what the next two major versions of Java are likely to include. (Java 7 contents, Java 8 contents.) From the article: 'The JDK 7 and 8 JSRs represent Oracle's 'Plan B' approach for separating JDK 7 into two separate releases, splitting up features that were all originally intended for the Java 7 release. This approach is intended to help expedite new Java releases. Among the key components of the original Java 7 plan that are now set for inclusion in Java 8 are the Lambda and Jigsaw efforts. At JavaOne this year, Thomas Kurian, executive vice president, Oracle Product Development, explained that Lambda is all about bringing closures to the Java language. Kurian noted at the time that Lambda is intended to provide a more concise replacement for inner classes, as well as support automatically parallel operations on collections. Jigsaw is all about building modularity into the Java Virtual Machine.'"

Re:Java Community approval

[gutnor]

The change was proposed by the community. Sun lack of direction/focus has put enough misery on the release of Java 7 so the choice was to either to split the release in 2 part or release Java Vista some day in the future.

That has been years since the Java community is largely working outside of Sun, now Oracle, guidance. Innovation in the java world happens in third party open source frameworks that are born, mature and even reach legacy level before they make it into the Java JDK. Look at dependency injection, ORM, alternative languages on the JDK, ...

Obviously with a new boss around, especially with one with more teeth than the apathetic Sun, there is some territorial pissing going on between the big players: Apache, JBoss, IBM, ... but the split of the JDK is not such instance.

Re:One area in which I appreciate the Java's power

[h4rr4r]

The JVM is fast as hell these days. This line about java being slow is old news and no longer true. I say this as someone who does not really like java and tries to avoid Oracle products whenever possible.

Re:Closures?

[Anonymous Coward]

The lack of objects hasn't ever stopped any C program from working, but its lack is what inspired C++. Similarly, Java's lack of closures is what inspired C#.

Way back in the '90s, MS wanted to enable developers to use Java to write Windows apps. The obvious way to write Windows apps is for objects (like windows and buttons) to have events (like "mouse move" and "key down") that other objects can listen for by giving the object a function to call when the event is raised. Java had no clean way to write event listeners for VB-style form designers, so MS modified their version of Java (J++) to have closures (so you can say "use this object's OnKeyDown method to handle the KeyDown event"). Since Sun decided to go with inner classes instead, they sued MS and made them stop shipping any Java at all.

As a result, MS needed to write their own Java-like language for VB-style form designer apps, and came up with C#. Obviously it has closures (which it calls "delegates"), but in version 1.0 they only closed over an object's member variables. In 2.0 they were able to be anonymous and close over local variables in a method, and in 3.0 they gained the convenient lambda syntactic sugar. Some have called Java's inner classes "syntactic vinegar" because they're so cumbersome to use compared to C#'s (and most other languages') closures.

C#'s extension methods and generics combined with type inferencing and lambdas make it very concise to write code to return a list sorted by its item's name like this: list.OrderBy(item => item.name)
It's not unreasonable for Java programmers to ask for a similar boost in their productivity.

dom

Re:Still at 5 here

[sourcerror]

If you had to do J2EE developement prior to EJB3, you would appreciate annotations. Basically a lot of the stuff from XML files went to annotations.

Re:Go Java Go

[shutdown -p now]

For starters, to provide some context, here [java.net] is the current text of Project Lambda proposal - it's a fairly short and readable document explaining both syntax and semantics. Here [java.net] is the mailing list.

Project Lambda. The proposed syntax needs to be more Java-like.

There's a load of issues with semantics as well. They carried over a bunch of limitations from anonymous inner classes, such as inability to capture mutable locals (though at least you don't have to slap "final" on everything now, that will be inferred) - so it's still not true closures.

I was also rather disappointed by the way community input was handled in Project Lambda. Originally, it was unclear why they started it from scratch when there were as many as 3 major proposals for lambdas already (BCGA, CICE, FCM) which could be used as a base. The original claim was that community is too divided on those, and so a "clean slate" effort, guided by feedback of all interested parties, would reach a more universally accepted solution. What happened instead is that, after a lot of discussion on syntax and semantics, Sun - er, Oracle - just published their own spec and started to implement it right away. Pretty much all feedback on that was either quietly ignored, or disregarded under various reasons. This concerns both syntax and semantics.

With syntax it was especially disconcerting. Originally, there was a lot of discussion focusing on syntax on the mailing list, so Sun/Oracle folks declared a moratorium on it, saying that it's "not so important" and that "we can discuss it later", after semantics are figured out. Since then, their proposals have had a major unilateral revision of syntax, and that is seemingly final for the proposal given that it's what they plan to submit for JCP. So the syntax was effectively not discussed at all in any way that made a difference, even officially.

The only case of feedback on semantics seemingly making any difference was with respect to lexical scoping of identifiers in the lambda. Consider this code:

abstract class SamType {
int foo;
abstract int bar(int x);
}

class Test {
int foo = 123;
void baz() {
SamType f = #{ int x -> x + this.foo };
}
}

The question at hand was about what "this.foo" in the lambda body is supposed to mean. The original Sun/Oracle proposal wanted to have the same rules as for anonymous inner classes; in this case, since the lambda is an instance of SamType, this would mean resolving "foo" to SamType#foo on the lambda itself, and you had to write "this.Test.foo" to get the other one - again, same as with AICs. After a lot of negativity on the mailing list, they've changed it to use strictly lexical scoping - so "this.foo" now refers to Test#foo.

However, even in that case the attitude was interesting - when discussion started on the mailing list, Sun employees were quite dismissive of any criticism, and their response pretty much boiled down to "we believe users who're used to AICs will want lambdas to behave the same". Then suddenly they release a new spec with updated semantics, and no comments as to why they changed it, disregarding their own past arguments in favor of the old one.

So, as far as "community participation" goes, I'd say that Project Lambda has largely been a failure so far. We'll see if it favors any better in JCP.

As to its technical merits - we'll see when it gets released, but if this happens in its present shape, then I'm afraid that it is rather deficient to all competitors out there (Scala, C#...). Aside from capturing mutable locals, one other major issue that goes unresolved is that they had discarded first-class function types, so you have to make do with SAM ("single abstract method")

Re:One area in which I appreciate the Java's power

[martin-boundary]

Really? How many milliseconds does it take to load the JVM, initialize it, load the class files etc before the byte code even starts executing?

Whenever people talk about the JVM being fast, what they really mean is that it's fast when it's already running, and when one compares programs whose typical running time is much longer than all that extra overhead so that it can be amortized.

That's great as it goes, but it's no C++ when performance really matters.

Re:Closures?

[master_p]

Closures and delegates are different things: delegates are constructs that forward the invocation to another function, and closures are function objects that have some state of the program bound to them so as that it should not have to be passed explicitly to the function.

Nitpicking, I know, but I think it's in important distinction.

Re:One area in which I appreciate the Java's power

[svick]

The documentation is still there. And as for me, I like the documentation of .Net much more than Java's. For example have a look at the documentation of .Net's List<T>.Add() [microsoft.com] method, that includes detailed explanation of the method, its time complexity, example usage and links to the same method in other versions of .Net. Compare that to the documentation of ArrayList<E>.add() [oracle.com], which is little more than one line.

Re:Java Community approval

[Anonymous Coward]

Apparently you are the clueless one. Jython and Iron Python do not have the GIL.
Jython makes for a much richer development environment.
http://www.jython.org/jythonbook/en/1.0/JythonAndJavaIntegration.html

Re:One area in which I appreciate the Java's power

[Matt Perry]

How many milliseconds does it take to load the JVM, initialize it, load the class files etc before the byte code even starts executing?

Does that even matter? Java is most used in long-running programs, not programs that are starting many times a second. The startup cost is minuscule. Focusing on startup cost is as pointless as these reviews of linux distros that concentrate on how fast the distro boots. No one is sitting there rebooting over and over saying "look at how productive I am now."