Over a million developers have joined DZone.

The Java Versions War

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

 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.

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}