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

211–220 of 304 posts

Re: Java 18 / JDK 18: General Availability

#211

Post by kaba0 »

vorpalhex wrote: post #188
kaba0 wrote: post #162

Earlier quoted context omitted.

For a typical business app, I really don’t think there is all that much overhead. Java is very fast, virtual calls are basically free due to the JIT, and these apps usually don’t need that much cache coherency for issuing an SQL query for a request. It’s not decoding video.

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.

Re: Java 18 / JDK 18: General Availability

#212

Post by criddell »

native_samples wrote: post #204
criddell wrote: post #182

What's your favorite toolkit for desktop Java applications? I believe JetBrains use Swing and their stuff is pretty great.

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?

Re: Java 18 / JDK 18: General Availability

#213

Post by jillesvangurp »

pjmlp wrote: post #172
jillesvangurp wrote: post #152

Earlier quoted context omitted.

Kotlin is actually the natural upgrade from Java if you want something that feels more modern than Java. Very easy to switch to from Java: a conversion tool is actually built into intellij. For most traditional Java frameworks (like Spring or Quarkus), Kotlin has long been a first class citizen (support, documentation, custom Kotlin extension functions, etc.) and probably the easier language to use when you are start…

Currently set at 8% of Java languages. https://www.infoq.com/news/2022/03/jrebel-report-2022 Hardly a successor of anything outside Google's ecosystem.

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 people just are that conservative. Java was always popular with conservative companies like banks. Companies like that are likely not using anything released in the last six years. According to Jrebel, that's about half of the survey. You can read into that what you want. But it's kind of meaningless for new projects.

Kotlin had their 1.0 release only six years ago. Spring boot 2.0 followed two years later and that was the first version to incorporate a lot of Kotlin and add explicit support for it.

It would be more interesting to get some statistics for Spring Boot 2 projects and Kotlin usage. Or even break them down by point release (2.7 is coming out soon) and there should be a version 3 by november as well. I'd expect a jump in Kotlin users with each of those point releases. JDK 17 / Kotlin 1.6 are going to be the minimum supported version for v3.

So, the percentage of users of anything over java 12 vs kotlin users is kind of suggestive: 12% vs 8%. Modern Java seems to be not that much more popular than Kotlin. And of course there's a difference between people that have upgraded their JVM and those that are actually actively using the new language features in Java.

Re: Java 18 / JDK 18: General Availability

#214

Post by pjmlp »

jillesvangurp wrote: post #213
pjmlp wrote: post #172

Earlier quoted context omitted.

Currently set at 8% of Java languages. https://www.infoq.com/news/2022/03/jrebel-report-2022 Hardly a successor of anything outside Google's ecosystem.

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 InteliJ is a second class experience.

Re: Java 18 / JDK 18: General Availability

#215

Post by vips7L »

MBCook wrote: post #119
ape4 wrote: post #16

Earlier quoted context omitted.

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

For what it’s worth any decent IDE will warn you about that. But as a Java developer you know it’s wrong, Strings are objects and that’s not how you compare objects. The tricky one is numbers. Integer == int // fine int == int // fine numVarOne == numVarTwo // Uh-oh In that third example you better make sure they aren’t both boxed objects or BigDecimals. I’ve almost never seen the string one for some reason. It’s alw…

Integer == Integer actually works... sometimes, as long as you're within the Integer cache. It gets people all the time though.

Re: Java 18 / JDK 18: General Availability

#216

Post by MBCook »

vips7L wrote: post #215
MBCook wrote: post #119

Earlier quoted context omitted.

For what it’s worth any decent IDE will warn you about that. But as a Java developer you know it’s wrong, Strings are objects and that’s not how you compare objects. The tricky one is numbers. Integer == int // fine int == int // fine numVarOne == numVarTwo // Uh-oh In that third example you better make sure they aren’t both boxed objects or BigDecimals. I’ve almost never seen the string one for some reason. It’s alw…

Integer == Integer actually works... sometimes, as long as you're within the Integer cache. It gets people all the time though.

Yep. I’ve been bitten by that myself. It’s sneaky because it may pass all your unit tests because you’re using small numbers. Then it gets to prod with record number 2718 and kablooie.

Re: Java 18 / JDK 18: General Availability

#217

Post by throw_m239339 »

l5ymep wrote: post #18
kaycebasques wrote: post #5

This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.

Java developers are cheap and easy to find. There are libraries for everything that you would need - AWS SDK, Redis, etc. Performance is tolerable and can be improved with things like Micronaut and native ahead of time compilation (GraalVM).

> Java developers are cheap and easy to find

As opposed to what developers that aren't cheap? Node.js? PHP? C#? Python? I have no idea what developer you're talking about here. Do you think JEE developers are cheap?

Re: Java 18 / JDK 18: General Availability

#218

Post by zls »

jillesvangurp wrote: post #152
stonemetal12 wrote: post #88

Earlier quoted context omitted.

What else would you use? Java is the shark that ate everyone else's lunch. At this point all you have as alternatives in the category of "easy to use for backend type stuff" is C#, and go. Both of which have their pros and cons but on the whole aren't bad choices. I guess like bellbottoms, Java is making a fashionable comeback.

Kotlin is actually the natural upgrade from Java if you want something that feels more modern than Java. Very easy to switch to from Java: a conversion tool is actually built into intellij. For most traditional Java frameworks (like Spring or Quarkus), Kotlin has long been a first class citizen (support, documentation, custom Kotlin extension functions, etc.) and probably the easier language to use when you are start…

I'd been eagerly following Kotlin since it was announced in the early 2010s, and could hardly contain myself when I finally got to try it out in real life about a year ago. But... honestly, in 2021, it was underwhelming.

- Compiler performance, especially of mixed Java/Kotlin compilation, is spotty.

- Support and tooling maturity is way behind Java. I'm trying to use it with Bazel, but the support lags far behind the Java equivalents.

- Interop with Java libraries that use annotations or interfaces is maddening.

- Perhaps a matter of taste, but the `var` keyword is a blight, even in Java.

- for all the complaints about "== vs .equals" and that sort of thing, these are by now incredibly well understood pitfalls that are generally checked by static analysis, sometimes even at compile time now by e.g. ErrorProne

In the early days, when it seemed like Java development might stall because of legal hell, Kotlin was a breath of fresh air. But today now, Java is clearly on a path to cannibalize Kotlin's most valuable features. Record classes and pattern matching obviate the biggest draws of Kotlin, while maintaining the buttoned-up, no-fun-but-extremely-pragmatic rigor of the Java language.

Once the glow started to fade, I was left with a very boring, familiar question: what am I really gaining by using this new tool? Is it worth the cost? and on my list of problems I deal with daily as a Java developer, the problems addressed by Kotlin are now so far down on the list that it's not worth dealing with even the tooling friction imo. For me, anyways.

Re: Java 18 / JDK 18: General Availability

#219

Post by wiseowise »

marginalia_nu wrote: post #173
LordDragonfang wrote: post #163

Earlier quoted context omitted.

Python uses the `is` operator, which is semantically much more explicit (and arguably correct, though C#'s use of the `is` operator is probably more correct). edit: Kotlin uses `===`, which is another good option.

=== seems almost more dangerous. It's a lot easier to tell == from Objects.equals(a,b) than == from ===.

Seriously?

Re: Java 18 / JDK 18: General Availability

#220

Post by papercrane »

mmastrac wrote: post #208
kevincox wrote: post #202

Earlier quoted context omitted.

If you are leaking file descriptors in a production service it will absolutely break things. Generally most servers that aren't pushing the FD limit can get away with delayed reclamation of FDs but if you never claim them you will run into problems. Plus most code probably handles this poorly. I suspect it will often result in exceptions opening new files or connection which are just caught and retried forever, resul…

I believe reference queues are the way to go about this now. Once you wrap your brain around them, it's far simpler to reason about. The only really issue is that you effectively need to litter your code with queue checks, or dedicate a thread to watching them.

You can use the Cleaner API instead. It's pretty straightforward to use.

https://download.java.net/java/early_access/jdk18/docs/api/j...

Post reply on HN