Java 18 / JDK 18: General Availability • Hacker News Board

Re: Java 18 / JDK 18: General Availability

#281

Post by native_samples » Wed, Mar 23, 2022, 11:07 AM UTC

Strilanc wrote: post #209

native_samples wrote: post #193

Earlier quoted context omitted.

They removed much bigger things, and broke backwards compatibility in much bigger ways. Finalizers aren't really used much in Java except for safety checks ("you forgot to close this object"), which can go missing without breaking things.

What bigger things have they removed? I thought Java lived and died on promising forward compatibility.

Backwards compatibility. Forwards compatibility isn't well supported by Java, or any other platform. The best you can do is catch exceptions and route around them, or use reflection for that.

Examples of things that have been or are being removed more important than finalizers:

- As noted, SecurityManager deprecation

- JavaFX. It was bundled in Java 8, lots of apps were written on that assumption, then it was removed. They all had to be re-packaged.

- Web Start.

- Removal of access to JDK internals in general, which lots of stuff depended on.

- Removal of various Oracle Java specific stuff, e.g. the resource management/control API.

- Java EE stuff. Annoying because a lot of stuff used it only for a few utilities, and because it actually got renamespaced so you couldn't even just add in the packages from elsewhere.

And there were lots of other backwards compatibility breaks, e.g. when they changed the format of the version number a lot of stuff broke.Probably more that I've forgotten.

Java is a great platform and I use it all the time, but Java's backwards compatibility is highly overrated. They don't care about real apps at all, probably because they hardly use any. Their backwards compatibility is defined relative to their own specification, not working software, so important apps have broken repeatedly over time.

Re: Java 18 / JDK 18: General Availability

#282

Post by junon » Wed, Mar 23, 2022, 11:14 AM UTC

Banana699 wrote: post #225

junon wrote: post #28

Earlier quoted context omitted.

If you actually understand Java, you'll understand why this is wrong. Only newbies have confusion about this, most of which dissipates when you actually learn the language you're working with. Tired of this 20+ year old "flaw" being used as cannon fodder.

This is like saying that null references are a non-issue because it have been there since the 1970s and that "true" $LANGUAGE developers never collide head-first into invalid dereferences. If something is ridiculous and un-ergonomic, it stays ridiculous and un-ergonomic no matter what. Reference comparison by default is ridiculous and un-ergonomic.

Null references exist in every language with the concept of null. It has nothing to do with Java specifically, and Java gives you a lot of information to debug them.

Re: Java 18 / JDK 18: General Availability

#283

Post by kaba0 » Wed, Mar 23, 2022, 4:24 PM UTC

pkolaczk wrote: post #274

kaba0 wrote: post #153

Earlier quoted context omitted.

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

That’s just not how it works.

If no code path gets run enough times, then frankly, it simply doesn’t matter, they could have been written in bash and still be “fast enough”.

Like, I can’t fathom a program that doesn’t have loops where the actually important part happens. You simply can’t write enough “linear” code to make a modern CPU sweat even just a little. And if you do have said loop, than it will be JIT compiled.

Re: Java 18 / JDK 18: General Availability

#284

Post by pjmlp » Wed, Mar 23, 2022, 4:45 PM UTC

jillesvangurp wrote: post #277

pjmlp wrote: post #214

Earlier quoted context omitted.

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.

It isn't what Android devs say, always complaining about compilation times, IDE freeze ups with.

InteliJ is partially written in Kotlin, unless they decided to port everything on top of Kotlin/Native.

As for why Kotlin exists at all,

> And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.

https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...

Re: Java 18 / JDK 18: General Availability

#285

Post by igouy » Wed, Mar 23, 2022, 5:18 PM UTC

kevincox wrote: post #203

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.

"If you exclude the well performing languages java performs excellently." But that is what I think OP means. It isn't top tier performance, but it is in the second tier which I wouldn't argue for qualifying for "relatively good". FWIW I find that languages tend to fall into a couple rough performance groups: - Native at about x1 performance: C, C++, Rust, Fortran - Compiled GC at about 2x performance: Java, Go, Haske…

Maybe there's a chart…

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Java 18 / JDK 18: General Availability

#286

Post by igouy » Wed, Mar 23, 2022, 5:26 PM UTC

jollybean wrote: post #278

pulse7 wrote: post #275

Earlier quoted context omitted.

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.

> Go ahead and run some code…

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Java 18 / JDK 18: General Availability

#287

Post by igouy » Wed, Mar 23, 2022, 5:42 PM UTC

kaba0 wrote: post #211

vorpalhex wrote: post #188

Earlier quoted context omitted.

If you think 512mb of base memory usage is "nothing" and you're ok with slow program start times, that's probably fine. If you're like me and you sort of get sad when your program uses more than 64mb when idle because it feels wasteful, then yeah that overhead is pretty gnarly. "But we have servers with hundreds of gigs of ram!" you might respond - and sure, we do, but having resources doesn't mean you have to use th…

What about the fact that Java is the most energy efficient managed language? Not constantly crunching through memory to choose which memory should be freed is efficiency, not laziness/bloat. Sure, there are use cases where it is not a reasonable tradeoff, but for CRUD business apps, it is perfectly fine. Especially given that not all cores can be used uniformly.

Maybe `vorpalhex` was interested in any "most energy efficient" language, not just a "managed language".

Re: Java 18 / JDK 18: General Availability

#288

Post by jraph » Wed, Mar 23, 2022, 5:43 PM UTC

junon wrote: post #282

Banana699 wrote: post #225

Earlier quoted context omitted.

This is like saying that null references are a non-issue because it have been there since the 1970s and that "true" $LANGUAGE developers never collide head-first into invalid dereferences. If something is ridiculous and un-ergonomic, it stays ridiculous and un-ergonomic no matter what. Reference comparison by default is ridiculous and un-ergonomic.

Null references exist in every language with the concept of null. It has nothing to do with Java specifically, and Java gives you a lot of information to debug them.

That's right, but that also doesn't answer the parent's point to which I fully agree.

Re: Java 18 / JDK 18: General Availability

#289

Post by igouy » Wed, Mar 23, 2022, 5:49 PM UTC

munificent wrote: post #257

paulmd wrote: post #248

Earlier quoted context omitted.

> I also think it's a pretty decent language. The things people don't criticize about Java are mostly complaints about a certain style of programming in the 90s and less the language itself. (assuming that's a typo there, the things people don't like/the things people criticize?) I disagree on that point, I think the language itself was a problem. Java 6 and prior were very very verbose and very very slow. I think th…

> (assuming that's a typo there, the things people don't like/the things people criticize?) Oops, yes, sorry. > Java 6 and prior were very very verbose and very very slow. It's kind of verbose, when looking at it from today's perspective, but at the time I didn't think it was that bad. I think they deliberately tried to be less cryptic and more wordy than C/C++ (which can often be impenatrable). I think they overcorr…

> But almost every managed language at the time had poor performance.

Slow compared to Smalltalk. Slow compared to Lisp.

Re: Java 18 / JDK 18: General Availability

#290

Post by pie_flavor » Wed, Mar 23, 2022, 5:56 PM UTC

I gotta say, I'm impressed with what they put together for the FFM. Previous iterations were terrible, in the way only Oracle can. In particular the ability to upcall and to manage mostly-safe handles off-heap with a declarative API is pretty nice. However, if I understand this correctly, FFI calls are going to be limited to modules explicitly authorized on the command line, which blows and defeats the purpose of having all this safe stuff being required instead of manipulating pointers directly. I assume there's some kind of reason for this but it seems like it's just going to be extra noise limiting time-to-hello-world without benefit. It still remains the most relevant part of P/Invoke that it's so performant and clean that the standard library makes all its syscalls with it, rather than getting magic backdoors from the runtime.