Live data from Hacker News

JDK 8 Release Notes

oracle.com

101–110 of 314 posts

Re: JDK 8 Release Notes

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

You have probably encountered the occasional Java desktop app, without realising. If you can't easily tell it is Java, the development team have done a good job.

Two of my company's three products are a Java desktop app for Mac, and they look and feel like typical Mac apps.

Best practice? IMO you should spend significant time on the GUI making sure it feels native. Otherwise, Swing is still about as good as it gets for Java GUIs. JavaFX is supposed to be more modern and superior, but lacks the large-scale support and third-party component ecosystem that you find the Swing. Although I'd be mighty pleased to be proved wrong on that one!

Re: JDK 8 Release Notes

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

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.

The Lombok stuff is pretty nasty, all kinds of hacks to hook into the compiler internals in unnatural ways. If you want those features just use a language which provides them, rather than awkwardly bolting them onto a language that doesn't.

Re: JDK 8 Release Notes

#103

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.

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.

Not sure if I enjoy SBT but Scala/Play/Akka is definitely great

Re: JDK 8 Release Notes

#104
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…

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.

It's not the approach, but the capabilities:

1. State-of-the-art garbage collectors, which enable good implementations of lock-free data structures.

2. Excellent implementations of lock-free data structures (like ConcurrentLinkedQueue and ConcurrentSkipListMap) and other concurrent data structures (like ConcurrentHashMap).

3. A state-of-the-art work-stealing scheduler (ForkJoinPool), excellent for both parallelism (as used by Java 8's streams) and concurrency.

4. A cross-platform memory model specifying memory visibility across threads.

5. Access to CPU concurrency primitives like CAS and memory fences.

These building blocks are a great foundation for any concurrent application.

Re: JDK 8 Release Notes

#108
post #27
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.

I've always been reticent to learn these offshoot dialects of languages unless I really needed to. I'd much prefer it if they were treated as syntax experiments, and good ideas from them filtered back into the main language.

The problem is the rate things get filtered back to Java. I started using Groovy when I kept waiting and waiting for new language features. In 2003.

Re: JDK 8 Release Notes

#109
post #18
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…

I've been using Java since the 90s. The JVM is a pretty solid piece of engineering, but your post is pretty heavily loaded with hyperbole. There are plenty of other excellent concurrency platforms for example Erlang, Go, even the. NET CLR.

Re: JDK 8 Release Notes

#110

Earlier quoted context omitted.

No, actually, Java is a really bad language. It has a very complicated type system, but doesn't even allow you to express things like function composition or generic sums at the language level. Its syntax is stunningly verbose (e.g., no map literals; only now adding lambda literals; no type synonyms; no operator overloading). There is no macro system or method_missing or any other way of really extending the language…

What is complex about the type system?

I'm guessing he's referring to wildcards (http://cseweb.ucsd.edu/~atl017/papers/pldi11.pdf) and the fact that the type system allows this (which isn't really a complexity, but rather a deficiency):

Object[] foo = new String[1]; foo[0] = new Integer(4); // exception thrown here instead of a compile error.

Post reply on HN