Legacy Java Systems

I’ve had my fair share of working with legacy code.  I don’t think legacy code is a bad thing because its existence means it has addressed the majority of the needs of the business successfully enough to stay around.  However, as time proceeds, the business needs to change in order not to become a historic entity and so legacy apps need to be updated.  This is usually where the frustration comes in.  You have to work with older development practices and styles you may not be used to.  You also may have to source old libraries or application containers in order to get things to build and deploy. 

However, I would like to think you can make a green field out of anywhere. A lot of other people may disagree, but the legacy system does have the advantage of addressing business need that your own ‘from scratch’ green fields app may not (provided the business need is still relevant).  There was a recent article on info q: Eight Quick Ways to Improve Java Legacy Systems that talked about the following areas

  • Tip #1: Use a Profiler
  • Tip #2: Monitor Database Usage
  • Tip #3: Automate Your Build and Deployment
  • Tip #4: Automate Your Operations and Use JMX
  • Tip #5: Wrap in a Warm Blanket of Unit Tests
  • Tip #6: Kill Dead Code
  • Tip #7: Adopt a ‘compliance to building codes’ Approach
  • Tip #8: Upgrade Your JRE

I’ve used a number of these techniques, but there were some I hadn’t heard of before such as the jdbcWrapper that simply wraps your jdbc driver with a logger so you can see what part of your code executes what SQL. (Tip 2)

Using JMX to trigger cache cleanups as described in Tip 4 is a great idea.  Another useful thing I’ve seen is using scripts and creating a Javascript or Groovy console within your app so that live maintenance can be performed on production environments.

Tip 5 touches on breaking dependencies, which is what you see a lot of in the code base I use. I’d like to get to know more about how to do this

Tip 6 advised that the Emma code coverage tool can also be used to find production code that isnt run (in addition to stuff thats untested)

Tip 7 really rang true to me.  Its easier to bring in all your toys under the sun, but without a common plan, everyone will bring in their own frameworks to solve the same problem and make the app even more confusing to work with.  I like ‘toys’ (frameworks, tools, etc) but I know I can get carried away Winking smile

Leave a Reply