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

71–80 of 314 posts

Re: JDK 8 Release Notes

#71

Post by mbillie1 »

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…

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 debug with an IDE, which is easy, but to actually read Java code), and so on. I'm not a Java developer by trade, but I'm surprised that other people are surprised by Java being high-performing, and the JVM being a good platform. I mean, Clojure Scala and Groovy all run on the JVM, and we talk about them all the time!

Re: JDK 8 Release Notes

#72

Post by fournm »

strictfp wrote: post #59
portmanteaufu wrote: post #36

Earlier quoted context omitted.

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

They in this case happens to be the original author of Joda Time.

Re: JDK 8 Release Notes

#73

Post by neverminder »

chaostheory wrote: post #41
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…

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

In my opinion http://www.typesafe.com stack is the most powerful and consistent one running on JVM. Scala/Play/Akka/Slick/SBT speaks for itself and I enjoy every day of working with it.

Re: JDK 8 Release Notes

#74

Post by fosk »

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?

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

Re: JDK 8 Release Notes

#75

Post by iSnow »

Pxtl wrote: post #45
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…

Breaking backwards compatibility isn't really an option, but if the compiler and IDE would discourage the use of legacy features that would be best. Just remove the legacy/ugly methods and packages from the autocomplete process, and warn with recommendations/flag as deprecated. You don't actually have to break anything.

Actually, every IDE warns you if you try to use a deprecated method. They show as strikethrough in your source too.

There are things like http://docs.oracle.com/javase/7/docs/api/deprecated-list.htm... and IDE's know about this.

Re: JDK 8 Release Notes

#76

Post by muteh »

michaelt wrote: post #42
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.

If you aspire to make Java into the type of language we would arrive at if we redesigned Java from scratch today, it's not just a matter of adding good features but also removing bad ones. For example, you'd go directly to Joda-Time or JSR-310. Date and Calendar wouldn't be present at all. Whether Java should break compatibility to remove all the old cruft I'm not sure. The benefits of the cleaner design might not be…

I'm glad you added that last line, because that's basically the whole story. Java is /very/ backwards compatible, and it's got round the...errr...quirks of the early versions by having a massive ecosystem of alternative implementations. Some of these (like Joda-Time) are good enough to get widely accepted as the 'correct' implementation. I don't think anyone will argue when you say that that throws up some barriers to entry, but they're not massive barriers, the standard library does still work. Not having to rewrite your code every six months is much more important.

Re: JDK 8 Release Notes

#77

Post by dragonwriter »

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…

> I guess what I'm trying to say is it would be great if the language was informed a bit more with what's going on in the dynamic languages space like Go has been. I like how Python is about as clear as Java code is, but it's always seemed a little more quick and breezy to work with. This is something I think Go got right and it'd be great if Java sort of caught onto this.

Java has caught on to this, and a number of the new JDK 8 features reflect this (lambdas and everything related to them, default methods for interfaces, etc.) But Java isn't as unconstrained as a new language like Go is, because its got to support a huge stack of established code as well as making things more streamlined for new code.

Re: JDK 8 Release Notes

#79

Post by Zigurd »

hkphooey wrote: post #62
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…

What is best practice when it comes to Java GUIs? Would you recommend Java for building cross-platform desktop apps with near native UI performance? The IntelliJ IDE looks great but most Java desktop apps I've come across just look and feel weird. Not sure why there is such a big difference.

In theory, the Android runtime environment could be ported to most desktop environments. I have seen Dalvik running on Windows 7. I used to be CTO at a company that developed an Android runtime for WebOS. You might infer they could do the same for similar platforms. Jolla has demonstrated Myriad's similar technology running Android apps in Sailfish. So while there isn't as cleanly defined boundary between app runtime and OS as with JavaFX, which is designed to be cross-platform, in practice it is possible to move the Android runtime across platforms with good results. It should even be possible to put Android apps into realizable windows in desktop environments.

There is a lot to be said for taking an environment with a big following and making it cross-platform vs making a cross-platform environment and hoping for adoption.

Re: JDK 8 Release Notes

#80

Post by fleitz »

asdafa wrote: post #22
puppetmaster3 wrote: post #8

Earlier quoted context omitted.

The problem is not java the lang. It's the java developers. Looks like they moved on to do angular now.

I partly agree with this. I'm a systems engineer, but I have to touch some Java code from time to time. I always have an hard time with the amount of indirection an average Java developer can reach. Luckily a few smart guys were hired recently and they have past experience in contributing to the JVM and their approach to the code is completely different and much, much more simple to understand, and since they came on…

Isn't it amazing how fast applications can go when they stop doing things they don't need to do?
Post reply on HN