Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Java Versions War

DZone's Guide to

The Java Versions War

Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

 Java is portable, so you can run your Java applications on any operating system that supports Java.

But these days that is not enough. Your clients may have a Java version like 1.6, 1.7 and even 1.8. We won't even talk about old versions prior to Java 1.6. Major changes in Java were done in 1.7 and 1.8, bringing some unseen problems to our applications.

This is the case if your applications depend on many third-party libraries and frameworks. Why? Because your libraries and frameworks may be old and you need to update them. And sometimes, updating a framework is not as easy as changing the version number inside your maven pom file. Changing a framework may involve changing server versions, other libraries and many times changing even the Java code.

So it is not as easy as it seems to make your applications work on all Java versions. First you have a minimum Java version specified to users. This is ok, it is a requirement. But you should make your application runnable with all versions which are equal or bigger to minimum version.

When a new Java version appears, you should check if your application can run on it! If it cannot, you should make it do so! Otherwise, you will be informed by your clients and "your image" will not be the same to them.

Let's look at some small examples.

1. You have a Java 1.6 application server /client  and you want to offer an Web Service to access a JDBC connection through it. You create a class:

public class Connection implements java.sql.Connection

and you implement your methods. Someone who uses Java 1.7 and your web service client will tell you he cannot use your web service. Why? Because in Java 1.7, the Connection class has more methods and these are not implemented by your web service. In this case, your client must use Java 1.6 or you should upgrade your application to Java 1.7 and implement new methods.

2. You have a third-party library in your application. For example, xstream 1.3.1  gives an error with Java 7. So you will find out that you need to use a version bigger than 1.4.

3. Someone already has Java 1.8. Your server uses AOP with aspectj library and you have a 1.5 aspectj version. He tells you the server does not start because an error is raised and the aspects cannot be weaved. You will find that aspectj library you have does not work with Java 1.8 and you must upgrade it to 1.7 version.

What do you must understand from this?

Do not take for granted that if your application works with Java version X it will automatically and flawlessly work with any Java version Y > X.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}