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

[Anonymous Coward]

The language you'll learn at uni isn't generally to learn the language - the language is used to deliver programming concepts. The language is rather irrelevant - although you'll probably be inclined to find a job that uses the programming language you've learned. Search around and find a different language you like (possibly also OO if you're just starting out) and do your stuff in java for uni, and then try and do it again in the language of your choice.

Java at uni is just the train. But considering your name, and the fact you called it uni and not college, and that you're learning java, I could take a pretty good stab at which uni you're going to ;)

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

Re:Java Community approval

[matfud]

Well my experiance is developing on windows and linux. Testing on linux. Deploying on various different Sun boxes some sparc 8 and 9's and some T1000 and T2000. More recently the code was deployed on a series of intel based blades (installed by IBM) in a new data centre. So yes just being able to do that makes java work well.

Re:Java Community approval

[matfud]

Yes I have pushed java to it's limits. It mostly works. There some nasty things that will get you but trivially avoidable. When you have to put it on various machines it does just work. HP/UX I have not yet encountered.

Matt

Re:Java Community approval

[Chris Walker]

No. Learn as many languages as you can. You're less likely to believe that one language fits all needs that way. Java isn't going to suddenly drop out of use, there is too much investment in it.

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.

Re:It seems a little lean

[DrXym]

Java is a verbose language and many changes are not about implementing the kitchen sink but trying to make it terser and more expressive. For example most getters and setters are boiler plate, so why not some simple annotation / keyword which generates them at compile time and tags them for runtime inspection? What about partial classes so visual editors generate code into one file and devs can put hand written code in another file? What about closures for single method interfaces to remove reams of boilerplate? What about auto variables that infer their type automatically? What about something akin to the using keyword in .NET so we can safely release system resources without a mess of nested try / catch blocks (which very little code does properly) ?

None of these things would actually affect the byte code but they would make the language more tolerable, less verbose. Some of these things are making their way into Java 7 / 8 (e.g. project coin work fixes language issues including resource management) which is good, but frankly the pace of development sucks. The process is so glacial that it has disappeared up its own arse and done several loops by now.

Re:Plan B

[MrEricSir]

You mean the emergency birth control pill? Well Java does feel like it was aborted these days.

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.

Re:lifecycle?

[h4rr4r]

Considering COBOL still has a presence in the Enterprise world I really doubt Java will go away that fast. If they went maintenance only today, maybe in 10 years it would start to be phased out in the Enterprise and maybe gone in another 25 years.

Closures?

[Anonymous Coward]

I think the focus on closures is a fad. The concept has existed for decades, but suddenly if Java doesn't have them it's incomplete? Strangely, I don't think the lack of them has ever stopped a program of mine from working. So this seems like more of a pissing contest with C# than a feature anyone is really clamoring for.

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: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: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:Closures?

[jernejk]

Way back in the '90s, MS wanted to enable developers to use Java to write Windows apps.

Really? I was around int the '90s and have no recollection of that.

As a result, MS needed to write their own Java-like language for VB-style form designer apps, and came up with C#.

Please, don't be naive. MS first tried to poison Java by proprietary API (the same tactics Google is using in Android). When they failed, they created a copy of Java, invented a "new" language which is for some reason unbelievable similar to Java + some nice features and started the "developers, developers, developers" mantra. They called .net "java killer" internally, BTW.

Java was and still is a major risk for Microsoft.

Re:Closures?

[TheRaven64]

Closures and objects are identical in terms of the things that they can express. See the COLA papers from VPRI for some good examples - you can trivially implement anything using closures that you can implement with objects, and vice versa. Objective-C has used higher-order functions for decades without closures. They do make some things a bit cleaner, syntactically (although Apple's syntax is horrible), but if you can't live without them then you have problems.

Re:Closures?

[Haeleth]

Closures and objects are identical in terms of the things that they can express.

Any minute now someone is going to bring up Turing completeness and point out that in theory you could write any program in Brainfuck. And someone else is going to point out that closures in languages like C# are objects, just hidden behind some syntactic sugar. No, wait, I just did both myself.

The point is that for certain common patterns, such as event callbacks, a closure-like syntax is significantly more readable than a conventional object type syntax. Computational equivalence is an academic question. In the real world, the question is how efficiently code can be written and how reliably it can be maintained, and in that regard there is often a real benefit to reducing boilerplate code.

Re:Go Java Go

[certron]

Macros in Lisp were introduced in the mid-1960s and are a powerful way to extend that language. However, the syntax of Lisp is very regular, so adapting the power of the prefix notation of Lisp into a language with a procedural syntax like Java is not going to be too easy.

I'm a little surprised that there isn't more mention of Lisp in this thread, considering that the lambda calculus that it was built on is the source of the name for one of the language projects.

Being able to transparently extend your language is a powerful tool that Lisp exploits to full advantage, provided the programmer knows when to use them. The regular syntax, functions as first-class objects (treated the same way as variables), and the macro system are the three features that build upon each other to make it such a flexible language.

See footnote #5 for some elucidation, although I certainly didn't learn Lisp on my first try: http://gigamonkeys.com/book/macros-standard-control-constructs.html

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:Elephant in the room?

[Haeleth]

He also observes that reified generics would probably make Java itself a better language, and would be useful for Scala too. Which between them account for practically everyone using the JVM in the real world. Is it really worth hurting the vast majority of people (and driving some of them to competing platforms), in order to benefit a handful of tiny niche products?

Why the fuck bother

[melted]

Just take this call it Java 9 or some such, and fire the remaining Java compiler people. Keep the VM people. There, solved it for you Oracle.

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

[Alkonaut]

Sack the VM people too, at least those who decided that the implementation of generics should be through type erasure, in other words "type unsafety". Next, dismantle the whole community process (Whoever wants an open system please fork at this exit). If Oracle just puts its weight behind java, it could well be the needed injection it needs. Without the tools for parallelism, distributed computing and so on, java (both VM and language) will be a "mainframe" language.

C# shows what can be done if you have
a) lexical closures
b) VM-level generics
c) A process where the language evolves faster than through a vote by UN+dog.

If oracle just makes Java the "other" .NET, it will be useable, but as a commercial second fiddle, it will probably be irrelevant.
If oracle does not make java the other .NET, the slow community process will make the language irrelevant within 5 years anyway.

So of the 3 topics here (Language, VM, Process) the language is the least important for the future of java.

Re:Why the fuck bother

[shutdown -p now]

No, it's not because of too much FP. It's because Scala has some really weird stuff in it, such as implicit parameters (where values are conjured out of thin air if not explicitly provided).

Or, say, implicit type conversions for the left side operand of "." (receiver) - so in "a.b", if the type of "a" doesn't have member "b" in it, the compiler will look for all accessible conversions from "a" to something else which does have "b".

This kind of stuff means that you can be looking at one simple line of code, which actually does a lot more than you think it does due to all the implicit stuff happening behind the scenes. What's worse is that the above is possible even when you have just wrote that line.

Re:Why the fuck bother

[TheSunborn]

They reason they did implement generic with type erasure (Something they knew was not the best solution) was so you could compile your Java 1.5 code, and run it on a jdk1.4 stack which don't know anything about generics. (They did not want to update the bytecode format, and with that restriction, type erasure was the only solution). So it was more of a management choice.

Why sun thought this was a better solution, then updating the bytecode is something I don't understand.

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: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 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:Go Java Go

[chthon]

For a growing complexity in a certain problem domain, the border between configuration and the creation of a domain specific language becomes rather thin.

Re:Go Java Go

[logpoacher]

Definitely. We used to call it "PPL" - Property-file Programming Language - the tendency for simple name-value property files to acquire strange little bespoke syntaxes and nesting structures. The question isn't whether you will do it - it's how soon you face it and how elegantly you'll achieve it.

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() 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(), which is little more than one line.

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

[Anonymous Coward]

Java can never start as fast as C or C++, it cant be done. I needs to start all kind of housekeeping threads, and allocate different memory pools etc.

But it is true that in a theoretical reasoning that Java execution speed can be faster then C++, and thats cause the JIT may rearrange and optimize the bytecode during runtime, to take advantages of a specific hardware in a way that you may not do in C++.

More often It goes slower tho, cause we all know when we stop coding features in, its when the good cases goes through. Why would you continue then? The JIT works and that's about it. It has some optimizations thats cool, but I'm not sure it such a huge feature for selecting Java over C++.

The reason for selecting Java over C++ more tend to be that its like writing Object Oriented Basic, Java is simple. C++ is a bullet in the foot compared.

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