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

111–120 of 314 posts

Re: JDK 8 Release Notes

#111

Post by radiantsand »

bane wrote: post #27
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.

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.

It's a mistake to think of one "main" language. There's a limit to what can be fed back into the Java language. Other languages like Clojure and Scala have more than enough going for them and stand on their own merits. I'm seeing increasing numbers of teams relegate Java code to legacy status in favor of newer JVM languages.

Re: JDK 8 Release Notes

#112

Post by RivieraKid »

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.

Have a look at SWT. It's the best way to do Java UIs IMO. I don't know why it isn't more popular. It uses the native UI kits internally, so it feels and is 100% native.

Re: JDK 8 Release Notes

#113

Post by jayd16 »

melling wrote: post #19

Anyone know what Google is going to do about Java 8 compatibility on Android? Not being able to adopt lambdas on mobile is a bummer.

You can use most of Java 7 but not the new dynamic stuff. I'm told that lamdas will require this feature so we won't be getting that for a while.

This is total speculation, but they're also moving away from the DalvikVM to the new ART runtime. I'm hoping that they're keeping Java 8 in mind as that gets implemented.

Re: JDK 8 Release Notes

#114

Post by kriro »

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…

I agree that the JVM is pretty awesome and will only improve (lots of money is bet on it after all) but I think BEAM may fulfil some of the items on your "awesome runtime" list :)

Re: JDK 8 Release Notes

#115

Post by puppetmaster3 »

edwinnathaniel wrote: post #16
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.

That's a good sign. Y'all JS devs need to learn something from Java community (especially the engineering/quality side) even if you guys have to go through the pain of Java growth (small => medium => bloated => denial => acceptance => cleaning up => shaping up for the future).

It's a bad sign for .js devs: trouble ahead.

Re: JDK 8 Release Notes

#117

Post by radiantsand »

suyash wrote: post #85
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…

Java is the #1 language in the world. It's the best out there, period. http://jaxenter.com/java-is-the-world-s-1-programming-langua...

Best at what? You've link to a notoriously unscientific index which counts search engine results. How does that make one language universally better than all others "period". I've coded in Java for most of my career, but the blind blinkered faith in the language within the Java community never ceases to amaze me. It's one tool available among many, look a little further than that single hammer which you worship in your toolbox.

Re: JDK 8 Release Notes

#118

Post by smikhanov »

pron wrote: post #104
hugofirth wrote: post #55

Earlier quoted context omitted.

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 (a…

Could you please elaborate on #5? What you mean there is the fact that AtomicInteger implementation is actually using this primitives on your target platform, correct?

Re: JDK 8 Release Notes

#119

Post by pron »

smikhanov wrote: post #118
pron wrote: post #104

Earlier quoted context omitted.

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 (a…

Could you please elaborate on #5? What you mean there is the fact that AtomicInteger implementation is actually using this primitives on your target platform, correct?

It's more than that. AtomicInteger's implementation uses JVM intrinsics which are calls to methods in the sun.misc.Unsafe class, that, when JITted, are replaced by a platform specific machine instruction (where available), such as CAS or a memory fence.
Post reply on HN