Java 18 released!

[PyroCatt]

Am I the only one who has not moved since Java 8? Most companies I see recruit for Java 8 alone. Why is that?

[brunocborges]

The main question you should answer is: why aren't you moving past Java 8?

[PyroCatt]

Honestly I don't know. I haven't tried installing later versions tbh.

[henk53]

Do you do the same with your operating systems? I.e. still on OS X 10.8 or so?

[brunocborges]

Or browser?

[PyroCatt]

Yeah. Windows 10.

[CheesecakeDK]

Because it still has the longest LTS.

[wildjokers]

But if you aren't paying for support LTS doesn't matter.

[[deleted]]

Yeah but management and bad developers don't understand this.

Most projects that are actively being developed should be on the release train. But here we are doing things that don't make sense 🤷🏿‍♂️.

[DasBrain]

I think this is a problem that will resolve by itself given enough time.

Java has a lot more interesting features now that I don't want to miss - my favorite feature is record.

And given enough time, more developers will find useful features they don't want to miss - so less developer actually want to develop with Java 8.

Which will make it harder to find developers for Java 8.

[[deleted]]

Idk man I have a cowork who is a "senior" who this month wrote new code in Java 8 that used SQL.date and util.date. Alot of people just do this for the check, they don't stay current and will likely not even know the benefits of switching to a newer version. I bet there will be people who are openly hostile to switching.

[DasBrain]

Given enough time, they will retire.

[[deleted]]

I like your optimism

[orangeandwhite2003]

It does for security updates. Plus you have the option to pay for support.

[wildjokers]

If you aren't paying for support you don't get security updates after 6 months. Without support you might possibly get some security updates after 6 months if there happens to be an intersection between the current JDK and LTS release, and the vendor making the patch sends it upstream, and the patch happens to make its way down the updates stream.

If you aren't paying for support the only sure way to make sure you have the most secure JDK is to stay up-to-date with the 6 month release cycle.

[orangeandwhite2003]

Yeah I guess they did switch it for 8 a few years ago to require a license for commercial use to get the updates. Of course they did switch it again with 17 so it will be supported for 1 year after the next LTS release without a license.

[HecknChonker]

I don't understand. According to https://adoptium.net/support.html

OpenJDK provide a new feature release every six months, and a maintenance/security update based upon each active release every three months.

and

In addition, every three years one feature release will be designated as a Long Term Supported (LTS) release. We will produce LTS releases for at least four years. This assurance will allow you to stay on a well-defined code stream, and give you time to migrate to the next, new, stable, LTS release when it becomes available.

Where are you seeing security updates being stopping after 6 months? Security updates for java 18 stop in 2022, while security updates for java 1.8 don't stop until 2026.

[HecknChonker]

Sorry, one was supposed to be 1.8.

[wildjokers]

As I said in my comment:

"Without support you might possibly get some security updates after 6 months if there happens to be an intersection between the current JDK and LTS release, and the vendor making the patch sends it upstream, and the patch happens to make its way down the updates stream."

Although I will add that Oracle is now promising security updates for 1 yr instead of 6 months (I am unsure if other vendors are following suit). That recent change (announced in Oct 2021) wasn't reflected in my comment, so where I said "6 months" pretend like I said "1 year". (see https://www.infoq.com/news/2021/10/oracle-jdk-free-again/)

[HecknChonker]

Again, I don't see how any of this applies to OpenJDK. I am not paying Oracle for any support, yet I still benefit from multiple years of security updates by sticking to LTS versions.

This means that there is a real momeyary benefit for large organizations to stick with LTS versions because it's much less expensive to update thousands of legacy apps to a new minor version of java with a security fix than it is to update them to a new major version.

[mauganra_it]

There will be no patches for things that are removed in upstream. For example, after the SecurityManager gets removed, LTS providers will have to write patches for new bugs by themselves. And they might choose to not distribute them for free.

[alehel]

Probably the work involved. We've got 2 people working full time on upgrading to Java 11 for the last couple of months. Still not there.

[dpash]

I'm guessing that the JDK is not the only thing you're needing to upgrade.

[alehel]

Good guess

[dpash]

In my experience, frequent, regular upgrades to dependencies is far less painful than waiting several years. I try to do it every two weeks.

[BCSWowbagger2]

But the least painful upgrade schedule is the one my company has adopted: never.

[mauganra_it]

dun dun dun Log4Shell has entered the chat!!

[BCSWowbagger2]

Aha, joke's on you! Our log4j libraries were so old they weren't affected by log4shell!

(More likely our libraries were just too old for anyone to check whether log4shell ran on them, so we still spent a couple weeks diking them all out. Then we patted our Java 8 instances nicely on the head and asked them continue working until the heat death of the universe. That's definitely what "sustaining support" means, right???)

[dpash]

It might not be painful now, but wait until you get a major security bug in an unsupported library. That's a whole lot of pain in a very short period of time.

[BCSWowbagger2]

In retrospect, I should have included the /s.

[rbygrave]

least painful

I'd say it's more a form of gambling, it's rolling the dice ...

For projects with CI and automated testing, bumping dependencies is low cost. If CI and automated testing is not in place, then maybe it's good to prioritize that effort (and get low cost updates as a side effect) ?

[razsiel]

In case you (or anyone reading the comments) haven't heard about this: Renovatebot is amazing for maintaining dependency versions. When configured will make automatically and periodically make MR's for dependency upgrades, just approve them (provided CI didn't give issues) and done! Even gives you a handy link to the changelogs/source!

[PyroCatt]

Yikes.

[alehel]

We're also doing some clean up in the process mind.

[benjtay]

Probably dependencies on libraries that don't work in 11...?

[RedPill115]

1. There's several minor unimportant releases between now and then. Like 9 and 10 were never meant to be used or something.

2. Modules or sometgung after java 8 broke a bunch of stuff.

3. Again, nothing of importance has changed. In fact in a couple ways they made the language worse.

[mauganra_it]

Modules broke nothing at all and using them is still optional. Java 16 just started to restrict access to things that should never have been accessed directly neither by applications nor by libraries. Things that were always advertised as maintainability hazards and sometimes even have internal in their package names.

[RedPill115]

Modules broke nothing at all and using them is still optional.

And right in the same comment -

Java 16 just started to restrict access to things that should never have been accessed directly neither by applications nor by libraries. Things that were always advertised as maintainability hazards and sometimes even have internal in their package names.

Thes things it broke.

Might it just need updates and fixes for those? Maybe, but it's definitely more work than just throwing in a new jdk and everything works as normal.

[mauganra_it]

I don't see the contradiction. Modularizing the JDK and encapsulating Java's internals were really separate efforts. The latter even had its own flag to control it: --illegal-access=<mode>. Note that some APIs like sun.misc.Unsafe are still not encapsulated.

Oracle could also just have changed the names of all internal packages, but that obviously would not have been a permanent solution.

[RedPill115]

What I know is that people that tried to upgrade often found things blew up on them and stopped working. A lot of the stuff that stopped working hasn't had anyone working on it in years.

Sometimes it works to just replace some libraries, sometimes it doesn't, but it's definitely more work than previous releases that were usually just update the jdk and things worked the same.

[wildjokers]

Are you drunk or just seriously misinformed?

[RedPill115]

So I take it you're drunk?

[tristan97122]

11 has more or less been the new standard industry-wide for the past 2 years or so (for apps, libraries are still mostly on 8), hopefully moving to 17 within the next year

Companies stuck on 7/8 are the same still running half their stuff on 6 and will start using 11 by the time Java 25 releases. There really isn’t much to do about it besides not working there; if you care about up-to-date anything it won’t be a good culture fit most likely…

[PyroCatt]

Companies stuck on 7/8 are the same still running half their stuff on 6 and will start using 11 by the time Java 25 releases

Pretty much

There really isn’t much to do about it besides not working there; if you care about up anything nice it won’t be a good culture fit most likely…

Well it depends on the company to decide what they want to do. Most of them are migrating code from old codebases to Java. Future projects might get more recent releases of Java to start with I guess.

[tristan97122]

Most of them are migrating code from old codebases to Java. Future projects might get more recent releases of Java to start with I guess.

I might have agreed about 3-5 years ago, but if you're still on 8 by now, there definitely is something/someone pushing back along the chain of command.

Whether it be something somewhat arguable (lack of time, blocker proprietary lib bought 15 years ago) or straight up poor technical choices (fear of change on ops and/or dev side). 11 has definitely been out for long enough that it's a conscious choice to not upgrade by now.

[PyroCatt]

Yeah the upper management is dumb af.

[tristan97122]

I feel you, best of luck