Hacker News Reader

Comment by MBCook | Hacker News Reader

I have a friend working at a company that is having “very important” discussions about this.

They need to keep up with security patches (for obvious reasons) but the six month limit has them scared. The consensus seems to be that they don’t believe they can keep up with an upgrade schedule that fast and are thus forced to pay for support from someone or hope that the community backports security fixes far enough for the rate at which they feel comfortable upgrading.

It doesn’t sound like they actually know what their upgrade rate would be, but they’re sure that it’s much slower than six months.

View on HN

I am not sure I completely understand the implications of this. But, if OpenJDK is the reference implementation, and as long as someone is going to maintain Java 11, there really isn't much to worry. I worked for a company that completely relies on Java. They also relied on Apache, so they had on their roles two developers that wrote code for Apache and Tomcat. Making wild guesses here but - if OpenJDK project gets 300 companies with one contributor each to write code for them, they will continue supporting Java 11. Maintaining Java is in some way a responsibility of every company that benefits from it. Or maybe I am so out of touch with technology that I am absolutely wrong.

The question is, and we won’t know the answer until this is been going on for a while, how many releas(es) back will continue to get security updates from the community.

Will they decide on arbitrary long-term releases? Maybe 11 and 15 and then 19 get three years of support?

Or will the community extend the length of security patch releases by some sort of fixed margin, say 6 to 12 months, and leave it at that.

Right now no one truly knows how it’s going to work out.

I find it interesting that a company that pushes out updates much more frequently than every six months is uncomfortable updating the software THEY use every six months.

It’s not like there should be big breaking changes problems, you can rely on the TCK to know that your code will continue to work.

We know that RedHat is aiming to support Java 11 LTS for a minimum of 6 years and OpenJDK8 till the end of life of RedHat7.x

Source https://access.redhat.com/articles/3409141

Hiring developers to maintain a core OSS project that your company depends on is actually a really good idea! Besides securing the future of that OSS, you now have a "insider" on your team that knows the ins and outs of that software. Having some performance problems? Sue compiles the code everyday and can take a look. Need a special filesystem hook? Jane knows the code inside and out and can make it happen. Genius!

What's being missed here is there is a whole slew of vendors that support openjdk. Those patches will come from red hat, ibm, azul,.. as well.

The question is for how long. Three months? Six months? A year?

The community will provide updates, but it this point no one knows what the eventual pattern will be which makes planning based on it difficult.

Not sure that's relevant either. Within the target environments you're still looking at 5 to 10 years just for red hat: https://access.redhat.com/articles/1299013

Azul publishes this as well: https://www.azul.com/products/azul_support_roadmap/

Cursory google searching is all it takes to find these things.

Waiting 6 months also does not make much sense when it comes to security patches. It seems like spending time to engineer processes to allow faster upgrades (CI/CD deployments is one popular route), would be a worthwhile investment.

It's hard to underestimate how fragile some enterprise projects are, no unit tests, no CI, dependencies on an unknown number of 3rd party components, the original developers left years ago and so on.

Reply on news.ycombinator.com