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

181–190 of 304 posts

Re: Java 18 / JDK 18: General Availability

#181

Post by carimura »

tyingq wrote: post #4
halestock wrote: post #2

Here's the openjdk page which includes links to details of all new features: https://openjdk.java.net/projects/jdk/18/

This one looks interesting: "JEP 400: UTF-8 by Default": https://openjdk.java.net/jeps/400 It sounds like a good idea, but I can imagine lots of downstream breakage, some of it not immediately obvious, with apps that make bad assumptions. Edit: The risks section of the linked doc above does explain some of that, and there is some notable risk.

Here's a short interview with Naoto on JEP 400 https://inside.java/2022/03/22/podcast-023/

Re: Java 18 / JDK 18: General Availability

#183

Post by evacchi »

freedomben wrote: post #93

It's legitimately fascinating to see the rise of pattern matching, to the point that even Java will have it [1]! Combined with lambdas, this is a different language than the Java 1.5 that I first learned. If you would have told me that this would be valid Java code: static void testStringOrNull(Object o) { switch (o) { case null, String s -> System.out.println("String: " + s); } } I would never have believed you. And…

record patterns may come as soon as JDK 19 https://openjdk.java.net/jeps/405 fingers crossed!

Re: Java 18 / JDK 18: General Availability

#184

Post by gmokki »

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.

One thing that is not mentioned is security. There are java libraries for almost everything. And when something is implemented in Java it is much harder to exploit.

Python and node are both great but mostly just wrap C libraries, so If openssl or your database driver has a bug your fancy interpreted/sandboxed language does not help.

Java has existed a long time and developers have had time to reimplement many popular protocols and libraries. This can sometimes cause few % points of performance, but you get stability and the excellent monitoring&debugging.

For example, if I need to accept images from the internet I would use Java since there are pure java image libraries that cannot be exploited with unexpected data. At most it fails and everything is cleaned up.

Re: Java 18 / JDK 18: General Availability

#185

Post by rcoveson »

shellac wrote: post #132
desdiv wrote: post #105

>JEP400: UTF-8 by Default This changes the default charset of the Java APIs to UTF-8. I read that the Java 8's JVM's internal string representation is UTF-16 [0][1]. Is that still the case after JEP400? [0] https://docs.oracle.com/javase/8/docs/technotes/guides/intl/... [1] http://tutorials.jenkov.com/java/strings.html

Yes, that won't change anything internal. However: > ...JVM's internal string representation is UTF-16 Hasn't been try for a while. They switched to using a byte array internally for storage, plus an encoding. Currently that's either UTF-16 or Latin 1, unless compact strings are disabled in which case it's all UTF-16.

You're talking about implementation details of java.lang.String. The interface it exposes is still UTF-16.

Latin 1 has the special property that each of its fixed-width code units maps onto a single UTF-16 code unit. It is for that reason alone that CharSequence implementors can use it as an alternative to UTF-16. Imagine trying to implement `char charAt(int index)` if you're backed by a UTF-8 byte array (or UTF-32, for that matter)!

From a programmer's perspective, Java is pretty much as UTF-16 as ever.

Re: Java 18 / JDK 18: General Availability

#186

Post by giaour »

ok123456 wrote: post #147
stevoski wrote: post #138

Earlier quoted context omitted.

> Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application? You don't. Almost any Java program written ever will run on Java 18.

JavaFX isn't guaranteed to be in a JVM. You run into "deprecated" APIs that were removed. JVM options change, and that breaks how things are deployed. If the JVM were a stable target a site like http://whichjdk.com/ wouldn't be necessary. This is just how things are. It's Java fanfiction to say this isn't the case, and necessitates having multiple JVMs installed.

http://whichjdk.net seems to be a site that tells me not to use the Oracle JDK without a license? There's a listing of which releases were the first to include certain language features, but it seems to mainly be giving advice around JDK vendors, not JDK versions.

There are two kinds of backwards compatibility at play: BC for compiled artifacts (let's call this Java ABI compatibility) and BC for language APIs (Java API compatibility). I have run into issues trying to compile an application with one JDK version and then run it on another (specifically, I believe JVMs will generally not run artifacts compiled with a later JDK version), but API backwards incompatibility is really rare in Java.

I do recall having to do a bit of cleanup when a previous project moved from Java 8 to Java 11, since a ton of deprecated APIs were pruned in Java 9, but those APIs were published by the JDK authors as standalone JARs, so I could remediate by adding a maven dependency. JVM backwards compatibility isn't perfect, but it's a much more stable target than other languages I've worked in.

Re: Java 18 / JDK 18: General Availability

#188

Post by vorpalhex »

kaba0 wrote: post #162
vorpalhex wrote: post #10

Earlier quoted context omitted.

With Java comes the whole JVM which is equal parts blessing and curse. You no longer need to know a bunch of OS details, but you pay in overhead. From a business standpoint, there are lots and lots of Java programmers out there. Of course that doesn't reflect anything about the average skill of those programmers..

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 them. It is better to write small fast efficient programs than extravagant enterprise stuff.

Re: Java 18 / JDK 18: General Availability

#189

Post by Strilanc »

mwcampbell wrote: post #128

I'm pleasantly surprised by the deprecation of finalizers, with a plan to eventually remove them.

Wow, that's a really well-established feature to remove. But reading "JEP 421: Deprecate Finalization for Removal" [1] did convince me it's a good idea to deprecate it. I'm suspicious they'll never ever actually be able to remove them, given the reality of maintaining backwards compatibility.

[1]: https://openjdk.java.net/jeps/421

Re: Java 18 / JDK 18: General Availability

#190

Post by azth »

paulmd wrote: post #74
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.

To echo others: relatively good performance, incredible tooling/deployment infra (really best-in-class), intercompatibility with tons of other languages built on top of the JVM such that it can be functional/do actors/whatever your other weird approach is, relatively high productivity due to a large library base (not just the standard library but also a huge amount of stuff written to support android apps), and ease…

> 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.

Post reply on HN