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

191–200 of 304 posts

Re: Java 18 / JDK 18: General Availability

#191

Post by native_samples »

HelloNurse wrote: post #150
_old_dude_ wrote: post #135

Earlier quoted context omitted.

Since Java 9/11 (9 is not a LTS), String internals was reworked to use either 8 bits or 16 bits per char. [1] [1] https://openjdk.java.net/jeps/254

BMP forever! The most disgusting thing I've read today.

UTF-16 represents a fairly reasonable compromise, not sure what your disgust is for.

UTF-32 (with no BMP concept) doubles the memory usage of most international text and quadruples the memory usage of ASCII text (which is the most common), yet characters outside the BMP are barely used outside of emoji.

Native UTF-8 in memory makes character indexing a non-constant time operation, which would bite people badly in cases where they've written a loop over the indexes. This is of course the point at which you say, ah but what is a character exactly. If you go down this route you end up with Swift and Emoji Flag Calculus classes. The string APIs become incredibly convoluted or inefficient for the common cases. It hardly seems worth any kind of backwards compatibility break for this.

So Java does the pragmatic thing: String can switch between 8 or 16 bits per "character" and this is basically always good enough. If you care about woring with emoji or Egyptian hieroglyphs in memory, then you either have to deal with combining characters or just bite the bullet and decode to UTF-32.

Re: Java 18 / JDK 18: General Availability

#192

Post by native_samples »

thfuran wrote: post #100
vips7L wrote: post #86

Earlier quoted context omitted.

Some people like support contracts. It gives you someone to blame when the auditors come knocking.

But does anyone like being involved with Oracle? There are other java vendors that offer support.

There are, but Oracle employ the vast bulk of the JVM and standard library experts in the world so they are in a position to offer far better support.

Re: Java 18 / JDK 18: General Availability

#193

Post by native_samples »

Strilanc wrote: post #189
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

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.

Re: Java 18 / JDK 18: General Availability

#194

Post by azth »

ape4 wrote: post #16
jraph wrote: post #8

Earlier quoted context omitted.

I'll try: Java is a proven, boring and "easy" language without much surprise, with a big standard library and ecosystem.

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

In addition to what the other posters replied, the IDE will warn you about this.

Re: Java 18 / JDK 18: General Availability

#196

Post by azth »

Angius wrote: post #139
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…

Java turning more and more into poor man's C# with each release

More like a very reasonable C# that fits in your head :) Even C# programmers are complaining about feature creep.

Java's Project Loom will be superior to C#'s async/await.

Re: Java 18 / JDK 18: General Availability

#197

Post by ahtihn »

dfee wrote: post #40
junon wrote: post #22

Earlier quoted context omitted.

The language is simple. Reasonable performance, lots of opportunities to tune that performance without changing code. Great error handling. Works across all platforms in most cases. The tooling has a long standing reputation for being incredible, given what Eclipse and Jetbrains have done for the community. It integrates nicely with native code, and is easy enough to interface with (compared to e.g. Node.js and pytho…

Great error handling? What does that mean? Checked exceptions seem cool at first, but are really just nonsense… as your only real way of dealing with this is: 1. Catch, log and rethrow, or 2. Wrap as a runtime exception (so you don’t have to change every method signature up to main()) Sure, there’s option 3: catch and handle… but this is used 1/50 times, and the ergonomics of (2) overwhelm the utility of this. BTW, v…

Okay,so what's a better way to do error handling?

Returning an Either is pretty much the same thing conceptually. Either you propagate the error or you handle it.

Re: Java 18 / JDK 18: General Availability

#198

Post by kevincox »

native_samples wrote: post #191
HelloNurse wrote: post #150

Earlier quoted context omitted.

BMP forever! The most disgusting thing I've read today.

UTF-16 represents a fairly reasonable compromise, not sure what your disgust is for. UTF-32 (with no BMP concept) doubles the memory usage of most international text and quadruples the memory usage of ASCII text (which is the most common), yet characters outside the BMP are barely used outside of emoji. Native UTF-8 in memory makes character indexing a non-constant time operation, which would bite people badly in cas…

> Native UTF-8 in memory makes character indexing a non-constant time operation

The only reason that Java's UTF-16 has constant time indexing is because they use a braindead definition of character which is "UTF-16 codepoint".

If you want constant time character indexing you need to go UTF-32. But obviously the downsides are too great for most users. So in practice everyone uses UTF-8 because it is usually the most memory efficient.

Plus it turns out that character indexing isn't actually that common of an operation, so it is really the right move for almost every application.

Re: Java 18 / JDK 18: General Availability

#199

Post by nneonneo »

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.

Python should really have done this for 3.x. The breakage thanks to using the system default locale is hard to overstate - PYTHONIOENCODING winds up being a bit of a PITA for writing cross-platform code.

Re: Java 18 / JDK 18: General Availability

#200

Post by native_samples »

dfee wrote: post #66
fifticon wrote: post #46

Earlier quoted context omitted.

Actually, i like it for basic desktop apps, because it just works, and i stay clear of the last 12 years of front-end dumpster fires, where nothing that is over 18 months old, can build, compile or get support anymore. In my day job, I inherit "fun" tasks as 'get this thing someone glued together with webpack4 and frontend-du-jour to work with webpack5 in 2022. Java thank you, any day of the week.

There are a lot of problems in the JS and Swift communities, as there are for Java. I think you’ve got to meet your customer where they are, and if you can ship Java desktop apps, and they’re happy… keep going. But you’re not shipping apps to their iPhones using Java. It’s either JS or Swift. And, on Android it’s JS or Kotlin. So the common target is JS.

You can ship to iOS with Java actually. That's the business model of Gluon:

https://gluonhq.com/

It's a combination of JavaFX, a custom controls library that implements Material Design and GraalVM native image. Whether you want a non-native UI toolkit on iOS is a separate matter, but it can be done technically.

In fact, you can ship JavaFX apps to the web too. It doesn't compile to megabytes of JS either - instead, the JavaFX app runs on the server and the UI is projected to divs and SVG elements on the fly. The browser provides native scrolling and text selection. If you have low latency to the server (e.g. same continent) it can work remarkably well. Check out https://www.jpro.one/ - the entire website is a JavaFX app.

Post reply on HN