Java is still available at zero-cost

Honest question: How often do people upgrade their production language?<p>Me: once in a decade, maybe. I&#x27;m still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I&#x27;m grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren&#x27;t significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading your library or framework can be more often, but I tend to still be fairly conservative. Upgrading your language for production twice a year sounds crazy to me.

I have a friend working at a company that is having “very important” discussions about this.<p>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.<p>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.

Up until around 2008, clock speed was increasing rapidly and the bottleneck to systems performance kept changing. Software was being obsoleted in a mater of years. Then things started changing; evidenced perhaps by Windows upgrades suddenly becoming a lot less relevant and Apple starting to steamroll more modular computer builders like Dell.<p>Mark my words, there will come a day where continuously upgrading software will start to have a clearly higher cost than old, boring and stable. 2018 to me is the first year that a software platform can have had a true decade to stabilise in an environment that isn&#x27;t constantly shifting and changing at a hardware level.<p>Maybe trends like in graphics cards will shake things up, but I believe the advantage is going to move to stable, slow upgrading, well supported platforms with large bases of well trained developer. Reducing LTS windows will be a disadvantage for the Java ecosystem.

Java moving to 6 month release cycles is good. OpenJDK is good. RedHat providing long term support is good. All of this is good.<p>Where I&#x27;m worried this fails is with dependencies. Also in the context of developing plugins for other Java projects. For example building a plugin for IntelliJ and the different versions of IntelliJ users may have.

Just for comparison....<p>Microsoft supports .Net Core LTS releases for three years....<p><a href="https:&#x2F;&#x2F;www.microsoft.com&#x2F;net&#x2F;support&#x2F;policy" rel="nofollow">https:&#x2F;&#x2F;www.microsoft.com&#x2F;net&#x2F;support&#x2F;policy</a>

One could argue that LTS software is just a trap (and a particularly lucrative one). I know that this is likely a couple factors that allow me to say this namely<p>1. I can rule over our dependency and technology choices with an iron fist if need be<p>2. I live in on post 3.6+ Python as our main language and for anyone with good CD&#x2F;CI you can always run your tests against the master branch and latest dev builds at least one or two versions ahead<p>Okay so with that said, I feel like LTS versions of software are a trap for this reason. You end up in situations where there is so much pain with upgrading that you end up spending more either more time slogging through incompatibilities in the upgrade pipeline the longer you put it off the worst this gets, or you end up in situations where you have to maintain a forked Verizon’s if the code base while you upgrade things or you have to do a lot of monkey patching and work around to just get things running (famously this is the approach GitHub used to upgrade from different versions of Rails)<p>The alternative is to pay money to companies that will maintain the version of what you are using, but even then you inevitably have to move forward and that leads to nasty vendor lock in<p>I personally believe that having a robust CD&#x2F;CI platform and a well tested code base allows you to by pass this whole charade. We always have our code tested against the next next incremental release in testing, the next versions dev branch and a rolling git pull and build that tests our code base. We really do expect things to break but it lets us plan with our working code quite accurately to avoid this problem altogether and now we largely update pretty close to release cadence.<p>I don’t know if this helps anyone but I suggest doing software development in this fashion will save you a ton of headache. Being up to date with rolling release strategies has helped our productivity immensely because we can think about our dependencies and we have really whittled down to just a few core ones l. At a certain point we also formed some of the smaller ones and find maintaining those ourselves has been a flawless experience

Nice idea on clarifying what the word &quot;free&quot; means in this context (gratis, not libre) by prefixing it with a dollar sign. This is the first time I saw this, is this usage widespread?

On a scale from 1 - 10 it gonna suck 15 when the tech you rely on is being bought by Oracle.

The TL;DR is that Red Hat and IBM are going to take over from Oracle as primary maintainers of java 8 (in the form of openjdk) after January 2019. That is likely to last through at least 2022.<p>Going forward Oracle will be primary maintainers of openjdk for each new version of java for six months. Every third version (starting with 11) the hope and expectation is that RH, IBM, et al will take over after those six months are up and continue to support those versions for at least several years.

The author exposes his agenda by downplaying Oracle&#x27;s decisions that impact Java availability to businesses and FUDing other options, e.g. he says that RedHat will push security fixes to OpenJDK first and repackage afterward, as if it was something bad.

What does this mean for me as an engineer who writes Java every day?

Was RMS right after all?<p>[1]; <a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;philosophy&#x2F;java-trap.en.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;philosophy&#x2F;java-trap.en.html</a>

&gt; Build OpenJDK yourself. [...] I suspect this not a very realistic choice for most companies.<p>Are they saying that most firms don&#x27;t have the ability to build software themselves, or is this a situation particular to Java where they don&#x27;t backport security patches and most firms aren&#x27;t on the latest major?

I am not well-verse in Java world and curious about one thing.<p>The valuable part of Oracle JDK is the GC. For example G1 is only going to be available on OpenJDK 9. What if there&#x27;s a new GC being developed, will OpenJDK have the new GC?

Kudos to RH. Here&#x27;s hoping that we don&#x27;t have to keep adding JIRA issues to update Java every 6 months. I have enough of this on the Javascript side as it is..

If Java is open and free, then why did Android decide to rewrite Java? I notice a lot of companies seem to avoid Java so there must be some sort of a catch.

Where is this is going to leave GraalVM and JIT for ARM? I believe both of those are exclusive to Oracle. And I was kind of excited to use GraalVM.

Boy, that Ask.com toolbar must be super lucrative.

Java is still available at zero-<i>price</i>

Adoptopenjdk! Azul! OpenJRE! J9! choice is a great thing!

what worries me most is the muscle memory of developers downloading Oracle jdk from oracle. If Oracle keeps is dark patterns, thousands of developers will be using the commercial tool and on the hook for license fees.

Maybe it&#x27;s time to start moving away from Java?