Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JDK 8 Release Notes

oracle.com

Post reply on HN
Print view View original

31–40 of 314 posts

Re: JDK 8 Release Notes

#31

Post by benjiweber »

netcraft wrote: post #2

> The expiration date for JRE 8 is 05/15/2014 How long till most people will target 8? I think we will wait for at least a few patches first.

We've using 8 in production for some time, as we slowly migrate things to it. We didn't want to start new projects without using Java 8 language features as it's such a dramatic change.

It has been feature frozen for a long time and even the pre-release builds have had a lot more testing and stabilisation than other software that people don't think twice about using.

There is of course a risk adopting new technology early, it depends what kind of things you are building/running.

Re: JDK 8 Release Notes

#32

Post by eropple »

hansjorg wrote: post #26
suyash wrote: post #9

Yay!! Java 8 is released!! My favorite parts: - invokedynamic : http://stackoverflow.com/questions/6638735/whats-invokedynam... - Project Nashorn : http://openjdk.java.net/projects/nashorn/ - lambda expressions : http://openjdk.java.net/projects/lambda/

Nashorn is said to be high-performance, and I've looked around for benchmarks several times since it was announced, but I still can't find anything but this: https://github.com/tadas-subonis/java-nashorn-performance-sa... What gives? Wouldn't a real comparison to Rhino and V8 (at least) be interesting? Edit: strike that. Found someone who ran Octane and SunSpider and compared it to V8 and Spidermonkey: http://wnamele…

I've been using JDK8 for a while, but no Nashorn on Android keeps me on Rhino. Which is unfortunate. Rhino's a pain.

Re: JDK 8 Release Notes

#33

Post by nicobn »

jpitz wrote: post #7
bane wrote: post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

There are warts in the standard library to be sure, but many of them have already been filled in by third parties like Apache Commons, Google Guava, and Joda-time. I'm sure there are others I'm not thinking of.

I was going to reply with exactly the same thing, and I'd add slf4j.

Re: JDK 8 Release Notes

#34

Post by ape4 »

bane wrote: post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

Lots of things in the library have multiple ways of doing things. Eg File, NIO. Generally if you use the new class you're in for a nicer time.

I agree about the regex literals. JavaScript does it right.

Re: JDK 8 Release Notes

#35

Post by mbell »

eropple wrote: post #30
netcraft wrote: post #6

Earlier quoted context omitted.

>If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that this is what groovy and kotlin attempt to do. groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

Groovy isn't attempting to fix Java, it's entirely different. (And it sacrifices type safety--even what of it you get with Java--and performance to do so.)

> And it sacrifices type safety

Groovy is optionally typed, you can have as much safety as you wish.

> and performance to do so

If you use static types, you can use @CompileStatic to get most of the performance back.

Re: JDK 8 Release Notes

#36

Post by portmanteaufu »

kevinpet wrote: post #12
latchkey wrote: post #10

Earlier quoted context omitted.

Agreed ...and jdk8 includes what was effectively joda-time (jsr-310) now. projectlombok.org also makes a lot of the language syntax ugliness quite bearable.

jdk8 completely breaks the entire value we get out of using joda-time, namely, that instants are unambiguous. It actually recommends using time and date without time zone.

Could you elaborate on this? I thought that JSR-310 and Jodatime were supposed to be nearly identical. Why would they introduce such a regression?

Re: JDK 8 Release Notes

#37

Post by sremani »

mariusmg wrote: post #17
bane wrote: post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

C# is a nice languae. Java...not so much. Properties, delegates, proper generics, LINQ and so on.

I agree C# from pure language point of view had a better road map and unlike Java which was sort of kind of run by committee did not need colossal consensus from disparate groups for new language features.

JVM vs CLR its a different story - I am hearing Microsoft in negotiation with Xamarin to buy/invest, that may make Mono get feature/implementation parity with CLR. Till then JVM is the only thing close to platform agnostic environment in town.

Re: JDK 8 Release Notes

#38

Post by bradleyjg »

jpitz wrote: post #7
bane wrote: post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

There are warts in the standard library to be sure, but many of them have already been filled in by third parties like Apache Commons, Google Guava, and Joda-time. I'm sure there are others I'm not thinking of.

Filing in the holes is nice, but without actually making it a design choice java embodies TMTOWTDI more than perl ever did.

For many common tasks there are 5 or 6 different standard library calls that seem to do the same thing, but 4 of them are to be avoided at all cost, but there's no depreciation tag and the official javadocs don't contain any pointers to the newer classes.

Post reply on HN