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

Java 12

jdk.java.net

Post reply on HN
Print view View original

131–140 of 478 posts

Re: Java 12

#131

Post by chrisseaton »

mehrdadn wrote: post #108
chrisseaton wrote: post #80

Earlier quoted context omitted.

Can you tone down your comments a bit, please? There's no need to be so aggressive. It's not nonsense, I'm not lying about anything, and I'm not running about crying. > Shenandoah implicitly relies on collecting faster than application allocates That's what the documentation tells you that you need in order to deploy Shenandoah. If you can't meet that then you don't get the claimed performance characteristics. If you…

It is nonsense though. I'm frustrated to see the same lie repeated over and over again. When nobody buys the lie a new GC comes out that everyone claims this time is really , truly going to do the impossible. With a giant invisible "implicit" asterisk that basically says "except when it doesn't, then it's your fault". It's been happening for... over a decade now? I don't even remember. > Shenandoah implicitly relies…

It's not complicated - the claim is that the pause only needs to be long enough to scan and update the root set twice and perform a little book-keeping, provided that allocation is slower than collection. That's black and white. Either Shenandoah is working correctly or you need to reconfigure.

How do you know if allocation is slower than collection? The logs tell you. This is the same as any performance requirement - you need to test it empirically.

If you think there's an issue with the claims of Shenandoah then you should publish your work rather than just abuse.

Re: Java 12

#132

Post by pjmlp »

ocdtrekkie wrote: post #16

Meanwhile, most enterprise apps still seem to only work with JRE 8. And those which I know of have elected to replace Java rather than upgrade.

We have quite a couple of them running happily with Java 11.

Re: Java 12

#133

Post by _bxg1 »

ilovecaching wrote: post #64
_bxg1 wrote: post #33

Earlier quoted context omitted.

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements). More importantly, the JVM ecosystem is m…

It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.…

> It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.

I categorically disagree. Nearly any program has pieces that benefit from OOP and pieces that benefit from FP and everything in-between. The most prevalent and useful languages support multiple paradigms (C++ is a mess for other reasons).

Re: Java 12

#134

Post by swsieber »

vbezhenar wrote: post #20
crooked-v wrote: post #4

Still nothing to handle checked exceptions in streams properly... sigh.

I wonder why they didn't use generic exception type in their java.util.function classes. That would propagate checked exceptions statically. Something like @FunctionalInterface interface Function { R apply(T t) throws E; }

Ah, that's because java generics don't work with exceptions.

Re: Java 12

#135

Post by spricket »

Gimpei wrote: post #66
azhenley wrote: post #6

The most interesting new feature I think is the Shenandoah GC. The summary from [1]: "Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB." The original algorithm…

Will this help spark performance at all? I remember having to make a lot of GC tweaks in order to get some of the larger jobs to run.

It should help performance on almost any JVM app, but much more on large heaps.

The GC time is lower and multi-threaded but most importantly the "pause time" is low and nearly constant (based on root set size)

The old GC's all scaled pause time roughly linearly with heap size. Apps that created a lot of garbage would have all their threads yielded for large amounts of time.

Now, essentially, it doesn't matter how much garbage you create. This is awesome because you used to carefully watch how many allocations you made to avoid bad GC times. Now it doesn't matter. Make as much trash as you want and the GC will deal with it

Re: Java 12

#136

Post by fnord123 »

ocdtrekkie wrote: post #16

Meanwhile, most enterprise apps still seem to only work with JRE 8. And those which I know of have elected to replace Java rather than upgrade.

Part of the issue is that a lot of libraries target jdk 8 since that's what Android supports.

Re: Java 12

#137

Post by vbezhenar »

aardvark179 wrote: post #52
geophile wrote: post #15

Are they ever going to release value types?

Adding values is a huge task because they are a big change at the VM, language, and library level. You can read about some of the latest plans in draft form at https://mail.openjdk.java.net/pipermail/valhalla-spec-expert... . Rest assured progress is being made.

Sounds like we won't have them in the next LTS, so probably another 5 years at least.

Re: Java 12

#138

Post by _bxg1 »

vorg wrote: post #83
_bxg1 wrote: post #33

Earlier quoted context omitted.

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements). More importantly, the JVM ecosystem is m…

> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it…

I wasn't aware of Groovy's roots, but that doesn't diminish the point. It elected to take on Java's baggage; the JVM didn't impose it.

Re: Java 12

#139

Post by vbezhenar »

swsieber wrote: post #134
vbezhenar wrote: post #20

Earlier quoted context omitted.

I wonder why they didn't use generic exception type in their java.util.function classes. That would propagate checked exceptions statically. Something like @FunctionalInterface interface Function { R apply(T t) throws E; }

Ah, that's because java generics don't work with exceptions.

What do you mean? They do work with exceptions.

Re: Java 12

#140

Post by the8472 »

mehrdadn wrote: post #108
chrisseaton wrote: post #80

Earlier quoted context omitted.

Can you tone down your comments a bit, please? There's no need to be so aggressive. It's not nonsense, I'm not lying about anything, and I'm not running about crying. > Shenandoah implicitly relies on collecting faster than application allocates That's what the documentation tells you that you need in order to deploy Shenandoah. If you can't meet that then you don't get the claimed performance characteristics. If you…

It is nonsense though. I'm frustrated to see the same lie repeated over and over again. When nobody buys the lie a new GC comes out that everyone claims this time is really , truly going to do the impossible. With a giant invisible "implicit" asterisk that basically says "except when it doesn't, then it's your fault". It's been happening for... over a decade now? I don't even remember. > Shenandoah implicitly relies…

> which merely shifts the blame for the pause from the GC onto the application?

There is no shift here, this has always been how things work. GCs are not a magic wand that allow you to do anything with reckless disregard towards efficiency with zero drawbacks (neither do malloc/free). Improved GC algorithms strive to cover more and more real-world workloads. Sometimes they fall short. Sometimes the developer did inefficient things that could benefit from optimizations to decrease allocation rates. A classic example is the O(n²) string appending (+=) behavior for which one should use StringBuilders instead. It just puts unnecessary stress on the GC.

G1GC had issues with LRU-like in-memory cache workloads. Some of those were improved with ongoing G1 development, but ultimately the new concurrent collectors (ZGC, shenandoah) solve those problems better since their pause times do not explode when many inter-region pointers need to be updated.

Post reply on HN