Update old java project dependecies to the leatest

I have an old (~2005) java EE project which I would like to update to the latest dependencies.

The web project doesn't have any software project management tool like Maven or Gradle.

Some dependencies and versions:

  • hibernate 2.0
  • struts 1.1
  • mysql 3
  • tomcat 5.0.29
  • java 1.6

Yes, it's this old.

I would like to update to the leatest TomCat, Hibernate, and MySql. If it's not necessary, I won't update Struts. What is the best way to do it? Do it version by version or just jump to the leatest?


  • We can't tell you what is strictly necessary to upgrade the dependencies. It depends on the nature of your old application and what your reasons for upgrading are. However, looking at the dependencies, these are some inherent reasons to upgrade:

    • Java 6 is end-of-life. The last public release was in April 2013. Since then there have been numerous releases that were only available to people with support contracts. Many of these were security patches. (It is still possible to get a paid support contract for Java 6 from Azul, but only until 2027.)
    • MySQL 3.x is end-of-life. From what I can make out, MySQL AB ended support for MySQL 4 (and earlier) in December 2008. There are likely to be unpatched security issues. (According to, there are 196 vulnerabilities against MySQL 4.0.1 ... but the methodology is unclear.)
    • Struts 1 is end-of-life as of 2013-04-05. There are many security vulnerabilities listed for Struts (in general) here: Some of these are for Struts 1.x, though it is not immediately obvious if any remain unpatched in the last release (1.13.10 from 2008)
    • Tomcat 5.x is end-of-life for security patches since 2012-09-30. (And that was for Tomcat 5.5.x.) The list of (patched) vulnerabilities for 5.x is here:
    • Hibernate 2.0 is end-of-life. I haven't been able to determine when support ended, but given that Hibernate 3.0 was released in 2005, we can safely say it was a long time ago.

    Security vulnerabilities don't always need to be fixed. It depends on 1) how exposed the application is to untrustworthy people, and 2) the possible impact of someone exploiting the vulnerability. And there are potential mitigations; e.g. blocking any external access to the database.

    The other thing you wanted was advice on whether to do everything at once, or to upgrade the dependencies one at a time.

    I have a feeling it is going to be difficult whichever way you do it. For example, if you upgrade to Java 8 first, there is no guarantee that the old versions of dependencies will run on Java 8. (Though it is lot more likely to work than if upgraded all the way to Java 21 LTS. That's almost guaranteed to fail!) Likewise, if you upgrade to MySQL 8.x you are liable to have problems finding Java 6 compatible JDBC drivers.

    Can I put it to you that there may be another alternative. Throw away1 the old code-base and start again! The code-base is nearly 20 years old, and it would have been designed for requirements from 20 years ago, based on UI design, etc from 20 years ago. Even if you succeed in migrating it, and make cosmetic UI changes, it will still look and behave like an old product.

    1 - Not literally, of course. And there could well be core functionality / business logic that is independent of the "framework" of the EE application that can be salvaged. But even there, you will still most likely be using mostly Java 5 and earlier libraries and language features. A lot of good things have happened to Java since; e.g. lambdas, streams, records, etcetera.