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

Comments

Java Community approval

[jrumney]

Is there still a Java Community left to approve this? I thought Oracle had managed to alienate them all over the past 6 months.

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:Java Community approval

[Anonymous Coward]

It's hilarious how clueless you and most of Slashdot are. At Google, we're actually writing more Java code than ever, and Python is slowly being phased out. Pretty much all of the big companies in the area are consolidated almost entirely on a mixture of C and either Java or .NET. Python and Ruby are basically relegated to simple CRUD web applications where performance doesn't matter and threading is inconsequential. While Java is a pretty bad language, Python and Ruby aren't anywhere near being able to compete with it because all of the usable implementations are terrible. CPython, MRI and YARV are garbage, and it'll take years before they reach an acceptable level of performance and remove the GIL. In fact, once InvokeDynamic is added to the JVM JRuby will be the best Ruby implementation by a pretty big margin...

It seems a little lean

[msobkow]

Both releases seem a little lean on features compared to Sun's release schedule. On the other hand, they're starting to run out of reasonable features to add to the language without turning it into a kitchen sink.

Wait... what?

[Anonymous Coward]

Oracle owns Java now?

When did this happen?

Re:Wait... what?

[lloy0076]

They've probably bought the rock you're hiding under too!

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.

Elephant in the room?

[oldhack]

Fix the generics. Get rid of erasure and all its associated idiosyncracies and gotchas, and bring generics properly into JVM level.

Re:Elephant in the room?

[pmike_bauer]

Please, no.
Reified generics at the JVM level has unintended consequences for other language implementations targeting the JVM.

Ola Bini has an excellent take on why it's best to keep reified generics out of the JVM.
http://olabini.com/blog/2010/07/questioning-the-reality-of-generics/

Re:Go Java Go

[certron]

The funny thing about the great flexibility that the frameworks like Spring provide is that you are defining the functionality in the XML files instead of the code, but now you have to learn two languages. The nestable list structure of Lisp is almost the same as the hierarchical format of XML, and in fact, that is how they are often represented natively in Lisp XML parsers. Instead, you could just use one language, structure your data properly, and extend the language to fit your problem.

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:Why the fuck bother

[Xrikcus]

And who didn't have to deal with backward compatibility. Designing a language from scratch is a completely different problem from evolving one that's heavily used.

Re:Closures?

[dido]

Spoken like a true Blub programmer. Trying to go from a programming language that has true lexical closures like Ruby to a language like Java which doesn't is extremely painful. You get used to being able to write code that uses higher-order functions (and hence closures) to get stuff done.

Re:Go Java Go

[shutdown -p now]

For starters, to provide some context, here is the current text of Project Lambda proposal - it's a fairly short and readable document explaining both syntax and semantics. Here 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

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