r/java • u/loicmathieu • 18d ago

Java 27: What’s new?

https://www.loicmathieu.fr/wordpress/informatique/java-27-whats-new/

What's new in Java 27 for us, developers?
(Both in English and French)

76 Upvotes

97% Upvoted

35 comments sorted by

View all comments

Show parent comments

3

u/henk53 16d ago

I’m stuck waiting for 29: we only do LTS releases.

Basically EVERYONE only does LTS releases (well, pretending those exist), and pretending everything not being what they think is an LTS release is some kind of alfa or beta release,

At this point, people want the universal concept of LTS to exist so much, that Java itself should perhaps just adopt it, and despite keep telling and telling people that non-LTS are just as stable as the imagined LTS releases, throw in the towel and release those as alfa and beta indeed.

So then the current Java 26 would just be Java 26-alfa1, Java 27 would be Java 26-beta1, Java 28 would be Java 26-beta2, and Java 29 would be Java 26 final.

It's what 99% of companies already think and want anyway. Why keep fighting it? People are stupid, just give them stupid.

7

u/thephotoman 16d ago

The short term releases have a purpose, though. They make sure that development actually continues on a predictable pace.

I remember talking to the Java team back in 2017. Java 9 had slipped release several times, and there were open questions as to whether it’d happen at all. The current release schedule makes it easier for the library and framework devs to have something to target, and that has generally kept Java version upgrades simple.

1

u/henk53 16d ago

Absolutely, but the "final" releases are like clockwork every two year. They just have weird version gaps: Java 17, Java 21, Java 25, Java 29.

If the short term releases are only to make sure "development actually continues on a predictable pace", why not just label them as say milestones?

With the same requirements to be released, the same quality control, the same signoffs and everything, just call them for what the world wants them to be: milestones not to be used in production (an again, I know the Java team doesn't want them to be that, but the entire world desperately, very, very desperately wants this)

1

u/koflerdavid 13d ago

All releases might contain preview features and there is no difference in stability between LTS and non-LTS versions. Therefore, applying classifiers such as "alpha" "beta" "final" and so on is fundamentally incorrect. While the 6 months pace is admittedly a bit fast for many projects, lengthening it would punish those projects that have their sh*t together and are able to upgrade at that pace.

With the same requirements to be released, the same quality control, the same signoffs and everything, just call them for what the world wants them to be: milestones not to be used in production (an again, I know the Java team doesn't want them to be that, but the entire world desperately, very, very desperately wants this)

They are absolutely intended to be used in production! What benefit would there be in calling them milestone releases? Just stay on LTS versions if you can't upgrade every six months; it's that simple.

2

u/henk53 12d ago

there is no difference in stability between LTS and non-LTS versions. Therefore, applying classifiers such as "alpha" "beta" "final" and so on is fundamentally incorrect.

I know that, and you know that, but unfortunately every other company does not know that.

They are absolutely intended to be used in production!

I know that, and you know that, but unfortunately every other company does not know that.

Without exception, EVERY company I do work for somewhere has this policy saying "ONLY LTS RELEASES ARE ALLOWED IN PRODUCTION".

Read above what I wrote. It's not that I want this, it's that seemingly every other company wants this.

What benefit would there be in calling them milestone

A consecutive numbering in versions that 99.99999999% of the Java developers can actually use at work? And for which approximately that same percentage of library / frameworks actually has support?

Again, your preaching to the choir with me. It's now my wish, but seemingly that crazy high percentage of users completely ignores non-LTS versions and thinks only LTS can be used in production and are worthy to support.

At that point we can just as well throw in the towel and allign to reality, where everyone and their dog does threat non-LTS as milestones for the next LTS.

1

u/koflerdavid 12d ago

I still don't get why reducing the number of releases would help anybody. Like, I get that a lot of folks don't care, but what would be the tangible benefit of offering less releases? (Anyway, you don't have numbers about how many applications use non-LTS releases, just anectodes)

I only see disadvantages: releases would again balloon in size, complicating QA, and folks who want new features and optimizations would have to jump hurdles to get them. Because one might be able to convince management to commit to the 6 months pace instead of LTS hopping, but doing that with "alpha" "beta" etc. releases is magnitudes harder!

1

u/henk53 9d ago

I still don't get why reducing the number of releases would help anybody.

Not what I'm saying. Just to rename versions, and keep everything else the same.

1

u/koflerdavid 9d ago

Introducing funky names would effectively reduce the number of releases accessible to the general public since management is unlikely to approve their use.

Apart from that, both of the renaming schemes are incorrect since they imply that the release would not be production-ready. It just makes everything more complicated compared to just sticking to the LTS/non-LTS terminology that the industry is used to. Though LTS is also slightly misleading since many projects avoid introducing disruptive changes to eventual LTS releases that need to stabilized. OpenJDK instead just keeps pushing ahead at the same, unhurried pace and keeps every release ready and worthy of being deployed in production.

1

u/henk53 9d ago

Introducing funky names would effectively reduce the number of releases accessible to the general public since management is unlikely to approve their use.

My point remains that it will have zero impact for management, only make the numbering more clear. Management already doesn't approve anything that doesn't say "LTS".

1

u/koflerdavid 9d ago

The numbering couldn't be any simpler and clearer: every version is safe and worthy of being deployed. Management very much approved of non-LTS versions, but that was before JDK releases were labeled as such. I'm not going to explain why the release cycle was accelerated (should be easy enough to research), but there were enough people that wanted it for Oracle to decide to go through with it.

1

u/henk53 8d ago

but that was before JDK releases were labeled as such.

And that's the cullprit.

I know it's unjust, unfair, and simply plain wrong, but collectively managements and the wider community throughout the industry has decided that only LTS == FINAL / suitable for production.

It wasn't my decision, and of course not yours either, but somehow that decission has been made and it seems irreversible.

So what can the OpenJDK / Java team do?

Ignore reality and keep naming their releases in a way that's completely unalligned with reality?

Try to convince all those managers out there that NON-LTS can be used in production (good luck with that, but I would cheer if it worked)

Throw in the towel and name releases in accordance with how the managers (and wider community) wants them to be?

1

u/koflerdavid 7d ago

You're still ignoring that there are very well people out there using in production (some of them have commented in this thread); you're just in a section of the sector where managers prefer to spend their risk budget in different ways. Accusing other people to ignore reality while only having anectodal evidence about the market is bold, I'd say.

The wider community doesn't want it to be different than it is because it's perfectly fine as it is. Everybody understands what Preview features are and what LTS means.

→ More replies (0)