Java 12 • Hacker News Board

Re: Java 12

#461

Post by cztomsik » Thu, Mar 21, 2019, 12:46 PM UTC

MarkMc wrote: post #214

I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework. Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javas…

The success of javascript is hugely because of no dependency-hell (not being able to upgrade some lib to a new version, because it would conflict with some other lib which requires it in its current version and you can't have both of them loaded at the same time)

Re: Java 12

#462

Post by kartickv » Thu, Mar 21, 2019, 1:28 PM UTC

pjmlp wrote: post #378

kartickv wrote: post #252

Earlier quoted context omitted.

Is there a guide to the various GC algorithms? Suppose I'm running an app where pause times don't matter, and I want throughout or reduced memory usage. How much more of this will I get by switching to another GC algorithm? 2%? 20%? 40%?

Mostly profiling. Each JVM implementation (Azul, IBM, OpenJDK, PTC, Aicas,...) has their own collection of GC algorithms. And their behaviour depends pretty much on the application as well.

Thanks. I understand that the numbers require profiling to determine, but I wish there was at least a high-level guide like:

Do you want to optimise pause times? Use X. Optimise throughput without regard to pause times? Use Y. Optimise memory use? Use Z.

It may not be accurate in every case (no guideline is), but it would be a good starting point for the vast majority of us who don't know the pros and cons of various collectors.

Re: Java 12

#463

Post by java-man » Thu, Mar 21, 2019, 1:59 PM UTC

freeone3000 wrote: post #292

java-man wrote: post #272

Earlier quoted context omitted.

Decoupling might have benefitted JavaFX, but it did not benefit me who develops professional desktop applications for a living, and it did not benefit my users. If they wanted to decouple, they first should have created a cross-platform jpackager-like tool that generates native executables for major platforms. I remember JavaFX was launched with great fanfare as a modern replacement, which it certainly might have bee…

This tool is called jlink. https://docs.oracle.com/javase/9/tools/jlink.htm

does it create a native executable?

Re: Java 12

#464

Post by spricket » Thu, Mar 21, 2019, 2:15 PM UTC

ilovecaching wrote: post #190

Scarbutt wrote: post #185

Earlier quoted context omitted.

Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host. Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..

It’s a spectrum. Java is at the very end with Erlang. I have a lot of domain specific knowledge of The Beam. Go on the other hand has a very lightweight runtime.

Very true. Newer languages seem to be moving back towards native binaries. The promised advantages of JIT compilation have faded with improvements to compilers and profile driven optimization.

Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes

Re: Java 12

#465

Post by pjmlp » Thu, Mar 21, 2019, 2:41 PM UTC

olavgg wrote: post #407

pjmlp wrote: post #401

Earlier quoted context omitted.

More popular where? Had it not been for Google's adoption of Gradle for Android and it would have been left for Grails maintenance projects. And even then, the pressure for perfomance has been so much that it is being superceded by a Kotlin based DSL. How to improve Gradle has been a common talk at every Android conference since Android Studio has been introduced.

Everywhere? Google Trends says Groovy is just as popular as it was 10 years ago. The number of downloads has increased significantly but it is not because of Gradle, as Gradle bundles Groovy. It is also currently placed #16. on TIOBE Index And last, Groovy with compile static is in most cases, just as fast and memory efficient as Java. Some people always talk down Groovy, yet the numbers speak for them self. Before K…

"Cédric Champeau: Goodbye, Groovy!"

https://melix.github.io/blog/2019/03/goodbye-groovy.html

Re: Java 12

#466

Post by paulddraper » Thu, Mar 21, 2019, 5:42 PM UTC

vbezhenar wrote: post #23

paulddraper wrote: post #9

Earlier quoted context omitted.

I share the conclusion of the other statically typed JVM languages (Scala, Kotlin): checked exceptions are bad.

If they are officially bad, remove them from the language. It's a backwards-compatible change. Currently we are in a weird situation, when standard library does not work well with each other. It's like making iPhone without USB-C cable and Macbook without USB-A port.

> If they are officially bad, remove them from the language

java.util.Date is bad, but it's not getting removed. java.net.URLEncoder is bad, but it's not getting removed.

Re: Java 12

#467

Post by freeone3000 » Thu, Mar 21, 2019, 5:52 PM UTC

java-man wrote: post #463

freeone3000 wrote: post #292

Earlier quoted context omitted.

This tool is called jlink. https://docs.oracle.com/javase/9/tools/jlink.htm

does it create a native executable?

It builds a directory of files which contains a .bat to launch the bundle.

Re: Java 12

#468

Post by karussell » Thu, Mar 21, 2019, 8:43 PM UTC

gigatexal wrote: post #312

pron wrote: post #177

Earlier quoted context omitted.

ZGC, included in JDK 11, has a 1ms average pause time and 4ms max on some demanding benchmarks, and they're now targeting 1ms max pauses. https://www.opsian.com/blog/javas-new-zgc-is-very-exciting/

If it lives up to claims surely it’s a paid for add on?

It works really great with heaps >100GB and is included in the openjdk since 11. Note, that only linux is supported, I think

Re: Java 12

#469

Post by pjmlp » Thu, Mar 21, 2019, 9:55 PM UTC

kartickv wrote: post #462

pjmlp wrote: post #378

Earlier quoted context omitted.

Mostly profiling. Each JVM implementation (Azul, IBM, OpenJDK, PTC, Aicas,...) has their own collection of GC algorithms. And their behaviour depends pretty much on the application as well.

Thanks. I understand that the numbers require profiling to determine, but I wish there was at least a high-level guide like: Do you want to optimise pause times? Use X. Optimise throughput without regard to pause times? Use Y. Optimise memory use? Use Z. It may not be accurate in every case (no guideline is), but it would be a good starting point for the vast majority of us who don't know the pros and cons of various…

Here are some guides for different JVMs,

https://docs.oracle.com/javase/10/gctuning/introduction-garb...

https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/gen...

https://www.infoq.com/articles/G1-One-Garbage-Collector-To-R...

https://www.infoq.com/articles/tuning-tips-G1-GC

https://developer.ibm.com/articles/garbage-collection-tradeo...

https://www-01.ibm.com/support/docview.wss?uid=swg27013824&a...

Re: Java 12

#470

Post by zmmmmm » Thu, Mar 21, 2019, 10:10 PM UTC

ptx wrote: post #451

olavgg wrote: post #400

Earlier quoted context omitted.

Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension

What makes Groovy unsuitable as a replacement for Java, if the performance is now comparable?

For the masses, imho, all round Groovy just isn't polished enough and is too complex. We are bringing someone up to speed now and there is an enormous amount to teach. There are a range of pitfalls that you have to alert them to. Mind you, a lot of other Java replacements are like that (eg. Scala).

Particularly though, the static compilation is just not comprehensive enough. It tries to do type inference but it's limited and invariably you end up having to add type casts in ugly places to convince it that expressions are valid. Occasionally it actually flat out refuses to compile something valid and you have to find a different way to do it. Sometimes it compiles with one version of groovy and then is broken in the next. It works great though to selectively add to hotspots of code and in other places to speed them up and define them better.

Having said that, we are essentially using Groovy as a java replacement and for our team I think the above costs are well worth it. This is partly because we have a heterogenous application that is partly dynamic in its nature and Groovy's dynamic scripting ability is amazing for this. The fact we can code our whole back end in the same language makes it super easy and well integrated.