Experience aspect-oriented (AOP) programming in Java 1.5

For an experienced Java developer who has access to the source code, any program can be viewed as a transparent model in a museum. Tools such as thread dumps (dump), method call tracking, breakpoints, slice (profiling), and so on, let us know what the program is currently doing, what has just been done, and what will be done in the future. However, the situation in the product environment is not so obvious, these tools are generally not available, or can only be used by trained developers. The support team and end users also need to know what the application is doing at some point.

To fill this vacancy, we have invented some simple alternatives, such as log files (typically used for server processing) and status bars (for GUI applications). However, since these tools can only capture and report a small subset of the information available, and often have to show it in an easy-to-understand way, programmers tend to write them explicitly into the application. And the code wraps around the business logic of the application, and when developers try to debug or understand core functionality, they have to "work around that code," and remember to update the code when the functionality changes. The real function we want to implement is to centralize the status reports in one place and manage the individual status messages as metadata (metadata).

In this article I will consider the case of using the State Bar component in an embedded GUI application. I'll introduce a variety of different ways to implement this status report, starting with the traditional hard coding habits. I will then introduce a number of new features of Java 1.5, including annotations (annotation) and Run-time bytecode refactoring (instrumentation).

State Manager (Statusmanager)

My main goal is to build a jstatusbar swing component that can be embedded in a GUI application. Figure 1 shows the style of the status bar in a simple jframe.

Figure 1. Our dynamically generated status bar

Since I don't want to refer to any GUI component directly in the business logic, I will create a Statusmanager (state manager) to act as an entry point for the status update. The actual notification is delegated to the Statusstate object, so it can be extended later to support multiple concurrent threads. Figure 2 shows this arrangement.

Figure 2. Statusmanager and Jstatusbar

Now I have to write code to call the Statusmanager method to report the application's process. Typically, these method calls are scattered throughout the try-finally code block, usually one call per method.

public void connectToDB (String url) {
　 StatusManager.push("Connecting to database");
　 try {
　　 ...
　 } finally {
　　 StatusManager.pop();
　 }
}

The code implements the functionality we need, but it looks a bit confusing after dozens of or even hundreds of of times in the code base. Besides, what if we want to access the messages in some other way? In the later part of this article, I will define a user-friendly exception handler that shares the same message. The problem is that I hide the status message in the implementation of the method without putting the message in the interface to which the message belongs.