Live data from Hacker News

JDK 8 Release Notes

oracle.com

271–280 of 314 posts

Re: JDK 8 Release Notes

#271

I have to admit I thought Java was dead in the water after Java 6, but Java 7 while a fairly quiet release was a decent release and Java 8 actually moves the language forward into a better place. As for the future here's what I would like to see: - Separation of language and libraries. Really the JDK should just ship with just a very small core of classes and everything else should be optional installed via a depende…

I admit I find my-self thinking from time to time that I need to "return multiple values from this method". But this is not often, and in most cases I find that it is a result of bad design. A method should be short and have a single responsibility, that is at-least the java best practice mantra, having only a single return type help enforce this.

Re: JDK 8 Release Notes

#272
I'm surprised no one mentioned the departure of permgen space and the dreaded PermSize and MaxPermSize JVM arguments. While it was actually replaced with a new "metadata" space, the latter is mostly transparent, unlike the former. You can read more about the change here: http://java.dzone.com/articles/java-8-permgen-metaspace

Re: JDK 8 Release Notes

#273

Earlier quoted context omitted.

> Aside from terrific performance, the JVM gives you the best concurrency platform out there (though not the easiest to use) It's getting easier http://akka.io/ http://gpars.codehaus.org/ I think clojure is also actor based.

Don't forget Quasar: https://github.com/puniverse/quasar

On the off chance that readers aren't aware, pron, the GP, is the author of Quasar.

Re: JDK 8 Release Notes

#275
post #203
post #173

Earlier quoted context omitted.

I'm so tired of writing null checks ... Could the null checks of Java be compared to the ones used in C#? My C# code is often littered with ternary operators to deal with null values. And that's still not as safe as the Objective-C approach where one can just send messages to nil[0] which is really awesome imo. I guess I kinda wonder if I could avoid the null checks in C# somehow ... I figured using a design by contr…

> I guess I kinda wonder if I could avoid the null checks in C# somehow Without seeing your code it is hard to say, but using an object extension might work? On many occasions I've used object extensions to hide checking code deep inside the extension. C# really got that feature right.

Can you show an example of how this can be done?

Re: JDK 8 Release Notes

#276
post #238
post #98

Earlier quoted context omitted.

> Nashorn is going to get faster with time. It is not a browser engine so don't try to compare it directly with V8 etc. v8 is not a browser engine either ,it's a javascript engine,just like Rhino. you are mixing up Webkit with v8.

"v8 is not a browser engine either ,it's a javascript engine,just like Rhino. you are mixing up Webkit with v8." - I think you're partly correct but also confused. Webkit is a rendering engine and yes V8 is a JavaScript engine not a browser engine that was created for Chrome Browser by Google. It's used for Node.JS etc now but it's sole purpose was to make Chrome faster and that is not the same purpose of Nashorn - n…

And Nashorn is supposed to be faster than Rhino... Nashorn and V8 are both JS-engines, why wouldn't you compare them?

Re: JDK 8 Release Notes

#277
post #240

Earlier quoted context omitted.

This sort of reaction is surprising to me. Java has been a useable, performant language for some time now. The tooling is excellent, the JVM is astonishingly good, and it will run circles around Python, no less Perl. I don't think many of the arguments against Java are based on how it works once you've written it, but rather to the horrendous verbosity, class-explosion-as-a-design-pattern, painfulness to read (not de…

> I mean, Clojure Scala and Groovy all run on the JVM, and we talk about them all the time! 5 years ago those 3 languages were the talk of the town for alternate JVM languages, but things change. Scala's pulled way ahead of the pack, Clojure's consistent, and Groovy's on a downward trajectory, following in Beanshell's and JPython's footsteps. Eclipse users are drifting into Xtend, and IntelliJ users may look at Kotli…

I've seen very little interest in Xtend in general.

Re: JDK 8 Release Notes

#279
post #116

If you're curious about the developer-facing changes in Java 8, I of course recommend the blog entry we wrote up last year [1]. It's a bit hard to believe it's been a year. [1] http://www.techempower.com/blog/2013/03/26/everything-about-...

Superb post! Thanks for sharing.

Re: JDK 8 Release Notes

#280
post #89
post #74

Earlier quoted context omitted.

Methods are marked as deprecated when they're planned to be removed in the next version.

That's the story that gets told, but how often have they actually removed something after deprecating it? Does anybody have a single concrete example of a method that actually went away? http://stackoverflow.com/questions/18063599/has-ever-anythin...

System.getenv was deprecated (in 1.1?), and then replaced with an implementation that threw UnsupportedOperationException (in 1.2?) because it was considered to be non-portable.

Later they saw sense and re-implemented it and un-deprecated it.

Post reply on HN