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

51–60 of 314 posts

Re: JDK 8 Release Notes

#51

Post by mongol »

pron wrote: post #18
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…

A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving…

Do you have more info on the cleanup in Java 9? Will they remove some deprecated methods then?

Re: JDK 8 Release Notes

#53

Post by isuraed »

mongol wrote: post #51
pron wrote: post #18

Earlier quoted context omitted.

A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving…

Do you have more info on the cleanup in Java 9? Will they remove some deprecated methods then?

How do deprecated methods affect you? Just curious. Maybe I'm missing something.

Re: JDK 8 Release Notes

#54

Post by pron »

rooted wrote: post #47
chaostheory wrote: post #41

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.

Clojure is not actor based but has some terrific primitives for concurrency

Quasar's Clojure API[1] gives you very Erlang-like Clojure actors.

[1]: https://github.com/puniverse/pulsar

Re: JDK 8 Release Notes

#55

Post by hugofirth »

pron wrote: post #18
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…

A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving…

Is there any chance you could briefly enumerate some of the things that make the JVM's approach to concurrency so strong? I'd be interested.

Re: JDK 8 Release Notes

#56

Post by jrabone »

nicobn wrote: post #33
jpitz wrote: post #7

Earlier quoted context omitted.

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.

Because God knows, Java needs another logging framework. Seriously does ANYONE get any additional value out of the morass of crappy logging systems out there over and above System.out.println? Log4J is PARTICULARLY brain-damaged, with its refrain of "ooh, someone put a log4j.xml in their JAR (one of hundreds), that beats your log4j.properties.". Or SL4Js amazing performance of "1.6 doesn't work with Scala because of ambiguous varargs". Or who can forget the incredible log4j logfile appender with the global lock around the file I/O? Not to mention the interactions between SLF4J and org.whatever-it-is-this-week.Jetty's built-in crappy logging facade.

Really, NEVER has so much effort been spent for SO LITTLE REWARD.

Re: JDK 8 Release Notes

#57

Post by elwell »

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 over-objectizing everything

This. This is what I think of when I think of Java.

Re: JDK 8 Release Notes

#58

Post by grimlck »

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.

It doesnt recommends using time and date without time zone, it recommends using the right class for the right job. And sometimes the right class doesnt include a timezone

Suppose you have a webpage asking users for their birth date. What data type do you store that value in? Hint: You aren't going to prompt the user for the time zone they were born in.

Re: JDK 8 Release Notes

#59

Post by strictfp »

portmanteaufu wrote: post #36
kevinpet wrote: post #12

Earlier quoted context omitted.

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?

They thought they could improve on Joda Time while at it. It's java.util.logging all over again (sadly).
Post reply on HN