Eight tips for improving Java legacy systems

You're right, that's the problem: Even the Java system becomes a legacy system. Whenever we think of legacy systems, we think of large, creaking hosts that store large amounts of file data and only have COBOL access. But the fact is that Java is already a 15-year-old development language, and thousands of systems written in Java have been running for 10 years or more.

So, given that a lot of readers are working on a legacy Java system, I've come up with these eight tips to help the team update and activate their legacy Java apps based on their experience.

Tip 1: Using the analyzer

The parser provides functionality that no other tool can provide, allowing you to drill down into your application. If your application has not been analyzed for more than a year, then it will certainly have large chunks of inefficient code lurking in some dark corner. There are many different or free or commercial analyzers available on the market. For CPU analysis, my favorite is Jprofiler, because it is strong enough to analyze most of the problems and be easy to set up, especially if you use the Setup Wizard built into it. When diagnosing memory problems, my favorite tool is Eclipse Memory Analyzer, because it uses indexes that are recorded on disk rather than putting snapshots of the entire heap into memory.

Typically, hidden, depleted CPU code includes inefficient hashcode () or Equals () (which are called millions of times when scrolling jtable and Java collection classes), and some surprisingly inefficient classes that come from Sun's hands, Like SimpleDateFormat.

The parser may obviously make your application slow, so be sure to use it in a test environment.

Tip 2: Monitor database usage

In addition to displaying the details of your application's overuse of CPU clocks, parsers can also give hints about where your applications have been doing database operations for a long time. But better tools for monitoring data use are tools like proactive DBA or HP diagnostics, or any other vendor from your database product. These tools can tell you which code makes a lengthy SQL call and which code makes multiple calls to the same line in a short time. Tools from database vendors can also help find queries that block other calls, although in my experience such blocking problems are basically simply inefficient SQL usage.

I wrote a new tool called Jdbcgrabber, which allows you to visually describe which code is accessing which data tables. With this visual rendering, you can easily find code that accesses different parts of the database multiple times, and adjusts it to a consolidated request.

Tip 3: Build and deploy automation

Many legacy systems lack a completely automated way to build their code, let alone deploy it automatically. Automated builds and deployments are a straightforward, low-risk way to improve the efficiency of legacy system developers, and typically do not require code modifications.

Without an automated build and deployment process, new developers will have to reinvent the wheel, fighting back the same problems that predecessors had struggled with, and each time a recurring deployment problem occurs, the developer invents a different solution.

Although Maven is an excellent and widely used build tool, it has a stubborn need for your source tree structure and library dependencies, so it can be difficult to use it in legacy applications. But a good enough ant should be easier to use because it handles the legacy code structure more flexibly and is easier to adopt in part rather than in its entirety.

Tip 4: Automate your operations and use JMX

Another way to improve the efficiency of legacy applications without bringing the risk of modifying the code is to improve its operational dimensions. Many in-house development enterprise systems generally require a lot of unexpected hands-on guidance and maintenance, even if this is not the case.

Existing Java features can easily be exposed to people who are responsible for operations, without any negative impact, by using JMX. Many developers are familiar with JMX because they use JMX to interact with application servers such as JBoss and WebLogic, but they don't know how convenient it is to use JMX in their own applications. Any Java class can be exposed through JMX, with little or no negative effects and no risk.

For example, if your application has a local static hashmap as a cache, you can expose the functionality via JMX so that the cache is easily erased.

Once the application is exposed through JMX, the operations team or developer can operate the application in a good way without directly accessing the machine running the application.

Tip 5: Create a unit test

Once your changes to the legacy system destroy a feature, one of the biggest obstacles you face is coming. Some tools claim to be able to reverse-engineer the code and create unit tests for it, but I don't have much confidence in these tools. To be confident enough, your unit tests do cover the code you expect them to overwrite, and you have to create them yourself.

Luckily, creating unit tests for legacy code was not as difficult as it felt at first. I used the Michale Feathers "legacy Code modification algorithm" in working effectively with Legacy:

Confirm Modification Point

Find the test points

Breaking dependence

Writing Tests

Modify and Refactor

The trick to using this algorithm effectively is the 3rd: breaking dependencies. There are many techniques that can be used to do this, but most of them are about removing static references and hiding external references and complex code under interfaces and facades. Once you have this feeling of breaking dependencies, it's not a scary thing to touch the legacy code.