Why Use Current Software Components?

Social responsibility and liability considerations require your product to be immune to published attacks. Your company shall provide reasonable protection to all your customers. Therefore, you always include security patches in your product in a timely manner. Other approaches are deeply unprofessional and unethical. In some countries, you are liable if you do not update your software to avoid known security attacks.

You should use the actual Java JDK and JVM version because the community is concentrating their effort on the latest version. Oracle only provides public support for the latest two Java versions, e.g., in January 2018, Java 9 and Java 8 are officially supported. Java 8 support will stop at the end of September 2018, older versions are no more publicly maintained.

If, for some reason, you are using an older commercially but no more publicly supported JDK, you must sign a support contract with the Oracle company and pay for it. You cannot use deprecated JDK versions because nobody provides security fixes on these versions, e.g., Java 6 commercial support ended in December 2017.

If you include a deprecated JDK / JVM in your product, you willingly endanger your users and shall be liable for their losses.

Governments started to realize how unprofessional organizations are working. Recommendations and laws are grafted to force better security ^[2].

The component developers put tremendous effort to improve the non-functional aspects of their products. Performance and scalability improvements between Java versions are impressive. You shall not hinder your own customers to rip these low-hanging fruits.

Actual versions of standards - Unicode, HTTP protocol, time zones - help eliminate incompatibilities and subtle errors from use cases. Having older versions will hinder you from supporting actual timezone changes or extensions in the Unicode standard.

Good training and associated certification are only available for actual versions of languages, frameworks, or libraries. You will not find any training for Ada, Apache server 1.x, or any object-oriented database.

The articles in Stack Overflow and the community always cover the current version of components. So you are on your own for support or code examples for older versions of libraries.

Writing code for older versions of libraries, frameworks, or runtimes means backporting to older application interfaces and features. For example, if you do not have access to auto-closable resources, you have to write your own framework and software checks guarantying closing system resources. You should always free system resources in your application. The literature states this is neither straightforward nor error-free. It is the root reason why such a feature was added to Java.

Teams often forget the consequences of back porting. Later, when you adopt a more modern version of your dependencies, you have to remove all this now spurious code and migrate to the built-in concept. Otherwise, the code is no more maintainable and changes are error-prone.

In other words, you have to twice work when backporting, once to build it in, and a second time to later remove it. This solution is certainly not the most economical one.

No professional developer wants to write source code using JDK 7 or older versions. They want to develop using modern and powerful constructs such as lambda, modules, HTTP/2. I would state that not using such constructs disqualifies you as a professional engineer.

We observed how whole teams become demotivated because a huge part of their daily work was backporting to old environments.

I understand that geriatric software solutions do not allow you to use the latest versions. It is time to bury such products and to go on. The only open question is the date of the burial. Do not wait too long, decomposition is never nice to smell.

Maintaining or extending software based on old versions of libraries is just throwing money out the window. You need a solid basement to build on.