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

Java 18 / JDK 18: General Availability

mail.openjdk.java.net

Post reply on HN
Print view View original

271–280 of 304 posts

Re: Java 18 / JDK 18: General Availability

#271

Post by kaba0 »

azth wrote: post #267
jollybean wrote: post #258

Earlier quoted context omitted.

Javascript in V8 is more performant than Java on a lot of tasks, and almost always 'sooner'. V8 is focused on 'getting going quickly' and it does, very fast. Java takes some time to optimize for most tasks. Also, 'performance' isn't really an issue once you are past 'good enough'. I don't think most devs are worried about Java/Node/Python/Golang performance on the backend for most apps. Obviously not always the case,…

> Javascript in V8 is more performant than Java on a lot of tasks, Source? I constantly see companies switching from the likes of python and javascript to compiled languages after they reach a certain scale. I find Java to be extremely developer friendly, especially nowadays with features like pattern matching, records, switch expressions, and the upcoming project Loom Modern frameworks like quarkus.io are also a ste…

Javascript is much closer to java than to python in terms of performance. And due to the variability of the JIT compilers, it can sometimes be faster than java, but generally the latter wins out.

But the parent poster is right that the two teams did choose a different workload to optimize for, V8 being fast faster while java taking more time to JIT compile a region, but that is mostly due to the difference between their most-common uses, running websites’ code as soon as they load vs mostly running on huge—ass servers with sometimes terabytes of RAM.

Re: Java 18 / JDK 18: General Availability

#272

Post by kaba0 »

paulmd wrote: post #263
giaour wrote: post #35

Earlier quoted context omitted.

Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. (Though the 8->9 transition was pretty rough for some.) Compiled Java artifacts are usually portable across OSes and CPU architectures, so your build pipeline can be pretty simple even if your infrastructure is not. JVM performance is generally fine, and the language prevents y…

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. this has been the case in the past, but Java is gritting its teeth and making some breaking changes in the JDK11/16/18 era. libraries that mess with the unsafe/internal namespaces are the most prominent example - there are a ton of legacy libraries that are going to break fro…

Which is essential for the longevity of a platform. You can’t further develop the JVM if you are bogged down by code depending on the internals. Encapsulation by modules is hugely important, and if we are honest, anything that depended on internals were prone to bugs anyways. Sure it sucks, but they will update sooner or later

Re: Java 18 / JDK 18: General Availability

#273

Post by kaba0 »

darkhorn wrote: post #261
ape4 wrote: post #16

Earlier quoted context omitted.

Java is great, but here's a surprise: if (str1 == str2) { // oops }

Another surprise is it that it has issues on Turkish localized Windows operating systems.

What do you mean? Can you give a source where I can read more on that?

Re: Java 18 / JDK 18: General Availability

#274

Post by pkolaczk »

kaba0 wrote: post #153
runevault wrote: post #30

Earlier quoted context omitted.

Language with a fast runtime minus startup (although maybe they've fixed the startup since I last looked) that is incredibly tunable to fit your specific needs for good performance profile, while not needing to manage raw memory the way c or c++ would. Personally I prefer c#, but a lot of places already were using Java in significant ways before c# became good (IMO 2.0ish) and saw no reason to change.

Java’s startup only slows down when a ton of classes have to be loaded, e.g. that’s why Clojure’s repl takes quite some time as you are loading two standard libs. For a simple hello world it is below 0.1s.

But noone cares about hello world. You're not building hello-worlds in real life.

Slow startup time is a problem in automated testing of big codebases - when you aim to test the whole codebase, but each test alone does not stress any code path hard enough for the hotspot compiler to kick in. So basically most of your Java code in testing runs in interpreted mode, which is like 20x-100x slower than properly compiled and optimized C/C++/Rust.

Re: Java 18 / JDK 18: General Availability

#275

Post by pulse7 »

jollybean wrote: post #258
azth wrote: post #190

Earlier quoted context omitted.

> relatively good performance, That's kind of downplaying it right? Outside of "native" languages like C, C++, Rust, fortran, Java blows everything else out of the water.

Javascript in V8 is more performant than Java on a lot of tasks, and almost always 'sooner'. V8 is focused on 'getting going quickly' and it does, very fast. Java takes some time to optimize for most tasks. Also, 'performance' isn't really an issue once you are past 'good enough'. I don't think most devs are worried about Java/Node/Python/Golang performance on the backend for most apps. Obviously not always the case,…

Java is typed, JavaScript is not typed. You can make more performance optimizations if you know types. So this claim is unlikely to hold...

Re: Java 18 / JDK 18: General Availability

#276

Post by alblue »

krzyk wrote: post #233
hu3 wrote: post #20

Earlier quoted context omitted.

Thanks! So why would I pick Oracle's implementation?

Question is why would you pick any vendors implementation? OpenJDK is reference one build from the source which is then taken by vendors and tweaked and built.

Oracle’s OpenJDK is the only one that is built without supporting Shenandoah GC.

Re: Java 18 / JDK 18: General Availability

#277

Post by jillesvangurp »

pjmlp wrote: post #214
jillesvangurp wrote: post #213

Earlier quoted context omitted.

Those statistics are a bit misleading because there is a lot of legacy Java code out there. You can see that in the statistics for Java 8 in the link you provided. 37% is still stuck on Java 8. That's quite old. We're talking about projects that have not updated anything in close to ten years. And some even use older versions than that apparently. That's not because those versions were that good but because some peop…

Kotlin can target Java 8 JVMs, yet hardly anyone adopts it in a meaningful way without papa Google forcing it. It would also be interesting to compare those Spring Kotlin numbers against the versions back when Spring was equally motivated to support Scala and Groovy a decade ago. In any case it hardly matters when the platform only supports Java out of the box on the JDK, without extra tooling, and anything besides I…

Technically yes, but most users would run something more modern. It does not make sense to use Kotlin and then be conservative with the JVM runtime.

Intellij is written in Kotlin. It does Kotlin really well. Better than Java even.

Re: Java 18 / JDK 18: General Availability

#278

Post by jollybean »

pulse7 wrote: post #275
jollybean wrote: post #258

Earlier quoted context omitted.

Javascript in V8 is more performant than Java on a lot of tasks, and almost always 'sooner'. V8 is focused on 'getting going quickly' and it does, very fast. Java takes some time to optimize for most tasks. Also, 'performance' isn't really an issue once you are past 'good enough'. I don't think most devs are worried about Java/Node/Python/Golang performance on the backend for most apps. Obviously not always the case,…

Java is typed, JavaScript is not typed. You can make more performance optimizations if you know types. So this claim is unlikely to hold...

Sorry, but this is textbook.

Go ahead and run some code on V8 and the equivalent Java.

You'll notice V8 is 'extremely fast' at getting up and running, while Java takes quite some time - often thousands of iterations of a specific bit of code before it optimises.

Re: Java 18 / JDK 18: General Availability

#279

Post by jollybean »

azth wrote: post #267
jollybean wrote: post #258

Earlier quoted context omitted.

Javascript in V8 is more performant than Java on a lot of tasks, and almost always 'sooner'. V8 is focused on 'getting going quickly' and it does, very fast. Java takes some time to optimize for most tasks. Also, 'performance' isn't really an issue once you are past 'good enough'. I don't think most devs are worried about Java/Node/Python/Golang performance on the backend for most apps. Obviously not always the case,…

> Javascript in V8 is more performant than Java on a lot of tasks, Source? I constantly see companies switching from the likes of python and javascript to compiled languages after they reach a certain scale. I find Java to be extremely developer friendly, especially nowadays with features like pattern matching, records, switch expressions, and the upcoming project Loom Modern frameworks like quarkus.io are also a ste…

Source? Reality! :)

I've built V8 instances and run some tests, but you don't need to do that.

Just write some roughly equivalent code and run it in Chrome vs. JVM and see for yourself. It's not nuance or controversial, it will really 'stick out'.

In basically all cases, V8 will 'get fast very quickly', it reaches a high level of performance on the second or 3rd iteration of a bit of code, whereas Java takes thousands of iterations.

That's a very, very broad and crude generalisation, but you'll see it very clearly if you just try it yourself.

It actually does make a difference depending on what you are doing as well - if you're running as server that uses the same code paths all day long, and executes them 1K times per minute, well then Java is fine. But for things like UI I particular where yo need the code to react it's a problem.

'Developer friendly' and 'modern frameworks' are a another question.

Re: Java 18 / JDK 18: General Availability

#280

Post by native_samples »

criddell wrote: post #212
native_samples wrote: post #204

Earlier quoted context omitted.

JavaFX by far. The API is probably the nicest I ever used of any toolkit, it's got a lot of features, is maintained by multiple companies, is mature, has a well integrated WebKit control, good multimedia support, can do 3D effects, uses CSS, has a UI designer, is stable, runs on embedded, mobile, desktop and can be "projected" to web browsers using JPro, and most releases are just bug fixes these days. Currently full…

I think Jetbrains are a great example of Swing done right, who's doing the same with JavaFX?

Browse through the app gallery at https://www.jfx-central.com/home

(note: jfx-central is itself a JavaFX app, again running with JPro to be projected over the web, but you can also download it and run it locally).

Post reply on HN