Summary
Would you DIY your Java to save on support costs? Support can be expensive, but you get professional help. Doing it yourself with unsupported Java comes with the risk that you will do it wrong, take way too long, cause yourself unnecessary anxiety, and pay too much anyway.
In this post you will learn:
- Providing your own support costs money in employee time and lost productivity
- Running Java without updates can cause unplanned downtime
- A delay in updating your applications could cause you to break your customer SLAs
- With Azul, paid support includes patches and fixes as well as CPUs and PSUs
Whether it’s car trouble, home repairs, or technology failure, everyone faces the classic dilemma: Call a professional or do it yourself. Calling someone is expensive, but you get a trained professional. Doing it yourself comes with the risk that you will do it wrong, take way too long, cause yourself unnecessary anxiety, and pay too much anyway. Even if you have the ultimate set of tools.
What about your Java? Would you DIY your Java to save on support costs? Let’s take a look.
Oracle has several Java licenses, including the Oracle No-Fee Terms and Conditions License, the GPLv2+CPE, and employ-based pricing. It’s complex and confusing, and managing the licenses on your own can be a challenge. Even if you can manage the licenses, doing so can impact your ability to build new product features.
The Oracle Java version hamster wheel
Oracle releases a new version of Java every six months and releases a new Long Term Support (LTS) version every two years. You can use Oracle Java license-free as long as you are using the latest LTS version. You have a one-year grace period to upgrade the previous version when the newest version is released.
So even if you can manage your licenses and upgrade to stay license-free, you will spend a lot of time on upgrades that you could otherwise spend on building new product features. But at least your Java is free, right? Right?
If you’re not paying for Java, what are you paying for?
There are several costs in time, resources, and money that might not be obvious when you first think about the cost of Java. Let’s look at a few.
- Engineering costs: If nobody else is providing Java support for your company, your engineers have to do it. Providing support costs money in employee time, lost productivity from time devoted to upgrades instead of building products, and the potential for damage if things go badly.
- Unplanned downtime: If you’re using a free version of Java, updates will not be readily available like they would with support Java. Running Java without updates can leave you white-knuckling it and hoping applications don’t break and vulnerabilities aren’t taken advantage of until you can apply a patch. Sometimes a bug fix actually introduces a new bug, then you could be stuck in a position where you can’t apply the security patches, but you can’t apply the update because it breaks your application without support.
- Broken SLAs: If you can’t update your applications quickly enough, you could break the service level agreements (SLAs) with your customers.
- Fines for noncompliance: If you have a data breach, you could face fines. Many regions have regulations in place to manage how you store and use personally identifiable information and other sensitive information.
And if you get something wrong, your applications could stop working or you could owe some high licensing fees.
Are Java patches available faster?
Oracle provides two versions of each update. The CPU (critical patch update) is only the security patches, and the PSU (patch set update) is security patches plus everything else (bug fixes, performance improvements, and other changes). Sometimes bug fixes and other changes introduce a new regression, a new bug in the JDK. However, we have not seen any of those issues affect just the security-only update the CPU. So if you have access to the CPU and the PSU when an update is released, and potentially there’s a security vulnerability with a high criticality score, you can use that CPU to deploy it very quickly with the minimal set of changes. If you use the PSU, you and your customers could experience unplanned downtime that could be unbounded. If you can’t get a fix to the problem, then you can’t deploy that update, you’re not able to deploy the security patches you need to address that critical vulnerability, so you’re kind of stuck in an endless loop.
Is unsupported Java too risky?
Azul has extensive experience helping customers migrate from Oracle to open JDK. Azul Deputy CTO Simon Ritter literally wrote the book about it, Open JDK Migration for Dummies. To learn more about this topic, listen to Simon in an on-demand webinar, The Opportunity Cost of Free Java. It’s the first of a three-part webinar series on Java migration.
