Reduce Legacy from Java EE 5 to 7

posted by Roberto Cortez on

Code from Another TimeJava EE 5 was first introduced in 2005, while Java EE 7 came out in 2013. There is a 7 year gap between both versions and in technology terms it’s like a century.

Many organizations are still stuck using Java EE 5 and there are many valid reasons why they choose not to upgrade. Still, these become irrelevant if you look into some of the reasons to move forward:

  • Benefit from the Latest Improvements
  • Java 6 EOL in Q1 2013
  • Increased Maintenance Costs
  • Hard to keep Developers interested

These reasons are somehow debatable and may not be enough to convince someone to upgrade.

Over the last few years, I’ve worked in an application with a considerable dimension and just recently it was migrated from Java EE 5 to 7.

Stop the Legacy

Code Grow Graph

Every year, new features were introduced that increased the application code base. It even surpassed 1 Million lines of code! This fact alone is an indicator that it’s hard to navigate this huge code base. If the application keeps growing, this will only get worse with time. Since the beginning of the application inception, we can observe that the grow was steady with each year, until 2015, when the migration happened. Afterwards, the code still grew but at a slower pace.

How?

In fact, by changing to Java EE 7, it was possible to produce the same results, but by writing less code. This may not seem a very big deal with small applications, but when we are talking about 1 Million, it makes a huge difference.

Not only you are being more productive, by consuming less time to implement the same feature, but also the chance to introduce bugs is smaller, since you also have less code to mess around.

No one really wants to change old code, especially if it’s working and even worst, you don’t know exactly why it’s used. But there are a few easy to use features from Java EE 7 (and 6), that you can use straight away when moving from Java EE 5.

CDI

Remember the tedious work to get an EJB in a different context, like a Servlet:

Most of these can be simply replaced with @Inject.

No more Local Interfaces

Tedious to always have to define an Interface for your Beans, especially if they were only used locally:

Just Replace by:

Singletons

Old fashioned Singleton (maybe not the most correct way to do it):

You just change it to:

Validations

Since you didn’t have Bean Validation available in Java EE 5, sometimes you had to resort in doing things like this:

Now we can just use @NotNull and @Max annotations into the field that we want to validate.

JMS

It’s a pain to use JMS in Java EE 5:

With JMS 2.0 and Java EE 7 you can drastically reduce the code and use chaining calls:

Moving Forward

These examples are just the tip of the iceberg on how you can simplify your code. There are many more examples, but these are the main ones used in this project.

Please post your examples in the comments section.

Also, if you would like to learn more about check my session, Migration Tales from Java EE 5 to 7 which covers some of the solutions we had to implement to completely migrate an application. Each case is different and there is no right recipe, but it can give you a good idea on the path you need to walk to achieve your goal.

Slides:

Video:

Share with others!
  • Twitter
  • Facebook
  • LinkedIn
  • Google Plus
  • Reddit
  • Add to favorites
  • Email
  • RSS

Leave a reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>