Hacker News Reader

Comment by halestock | Hacker News Reader

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.

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

You're not wrong, which is probably why they did it in this release.

JDK 17 was an LTS release, and 18 isn't. The next LTS will be JDK 21 in September 2023:

* https://www.oracle.com/java/technologies/java-se-support-roa...

This presumably gives folks times to adjust before jumping between LTSes in production.

We like to give Oracle stick (and rightly so) but this is rolling/LTS done right: you break stuff in the release right after the LTS one, to give people time to adapt.

It was just a coincidence. They do it right: ship when it is ready. LTS is not an openjdk term it is something that vendors might offer for any jdk version.

> LTS is not an openjdk term

It's an Oracle term, and I expect the majority of OpenJDK committers and decision-makers are still from Oracle.

LTS was proposed by Mark Reinhold [1] who leads the JDK Project in the OpenJDK community in 2017. There was a lot of discussion [2] that resulted in many vendors supporting and adopting the LTS model.

It's a thriving ecosystem (which is great!) but yes, Oracle does contribute a significant portion [3].

[1] https://mreinhold.org/blog/forward-faster [2] https://mail.openjdk.java.net/pipermail/discuss/2017-Septemb... [3] https://inside.java/2022/03/22/the-arrival-of-java18/

Yeah, but OpenJDK commiters thankfully don't care about it.

E.g. look on the things introduced in JDK 16 and JDK 17.

LTS is a good gimmick for decision makers in companies, but developers also don't care about it (it is not LTS as in e.g. Ubuntu).

Oracle is proactively suggesting to test such changes in advance, ex. https://inside.java/2021/12/10/quality-heads-up/

Worth noting that if you can, don’t stay on LTS. It adds cost which many modern teams can avoid[1].

It doesn’t mean enabling Java 18 on Production on day 1, but certainly it means adding a Java 18 compiler to your CI, running tests using Java 18, etc.

[1] https://www.reddit.com/r/java/comments/o0m6g8/the_state_of_p...

Yes, newer JDKs should ideally be rolled into at least DEV and perhaps QA just so breakage can be found early and fixed early. STG/PRD of course is something else.

Even if you don't use any of the new features, there may be deprecation warnings and such that one should be aware of sooner rather than later. Tweaking early to ensure compatibility with current-LTS and future-LTS versions is worth some cycles: if you don't, you'll pay for it eventually when old(er)-LTS is inevitably retired.

This discussion immediately brings to mind all of the iOS apps that become completely unusable the day a major iOS update is released, and then take a week to fix.

I get that not everyone has spare time and energy, but it doesn't take that long to grab a beta, put it on a device (or load up the simulator) and find out. Leaving it until the last minute just forces you into a panic, and seems irresponsible when you had months to just test your product.

Most of the cases where this breaks anything, are already broken, it's just not visible.

I don't know, they may be broken in terms of approach and design. But when the charset changes, new and never-seen-before things will start arriving downstream.

I wouldn't be surprised if defaulting to UTF-8 inadvertently fixes more problems than it causes.

That was not the experience when MySql switched in v4.1, at least for existing apps. Probably for net new ones it was great. Maybe things are different now?

Windows default went over to UTF-8 from UTF-16 a few years back so its probably alignment with them especially with MS now rolling their own linux and java.

To the best of my knowledge, Windows still uses UTF-16 internally. They now support opting for UTF-8 as the charset in the 'A' APIs, but that doesn't mean Windows natively uses UTF-8.

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

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.

The link is in the email itself

Reply on news.ycombinator.com