Three Java Analyzer reviews

Overview

WHO implements the Java application without a problem? Well, let's be honest ... Code Analyzer is the only custom tool to solve this pervasive problem. In this article, Laurence Vanhelsuwé will review three commercially available Java parsers: Borland's Optimizeit suite, Quest software suite, 　　And the Jprofiler of Ej-technologies. Now the software is such a bulky, so many facets of the guy, that there is no development tool to allow programmers to complete their ideas at will. Even run--this elusive yardstick, when our code hates it when it's in second gear, and when our code runs at a speed, we love it--it contains too many related aspects.

The performance-related problems are as follows: Subjective user-perceived program speed and response speed. If we temporarily exclude the user factor, then the evaluation of the running speed is equal to the objective realization of the sum. These aspects are: algorithm selection, the use of the whole memory, the dynamic distribution and release of objects, as well as multithreaded design and running behavior. Helping you understand the dimension selection of your program at run time is the heavy work of the Code Analyzer.

In this article, I've considered three commercial Java parsers and judged which parsers are more likely to meet your needs:

· Borland's Optimizeit Suite

· Quest Software's Jprobe Suite

· Ej-technologies's Jprofiler

Analyzer principle

It's not surprising that these three products have a lot in common. All modern parsers start with the same starting point and constraints: the Java Virtual Machine Analyzer interface (JVMPI) (refer to the "Java Machine Profiler Interface" of the other columns). The Sun Microsystems API allows tool developers to interface or connect to the Jvmpi JVM, monitor how it works, and key events when the JVM runs any Java programs-from separate applications to applets, servlet, and Enterprise JavaBeans (EJB) Component.

Assuming that Jvmpi imposes a standard, equivalent game field on all Parser tool developers, the factor that distinguishes the developer is only the Meta feature of the tool (e.g., adding important values to the original JVMPI data and functional features, and more importantly, It should be no surprise that the drawing user interface (GUI) should be developed for these features.

As you see the rest of the product review, each of its self-forming or self-breaking GUIs has its own way of addressing the core issues of how to develop the original Jvmpi feature so that the efficiency of analysis and debugging can be maximized. Unfortunately, many applications that use large databases use a visual, intuitive, and truly user-friendly user interface, but none of the parsers can convince me that they have been more successful in this area.

The three parsers reviewed almost all have the same profiling session configuration capabilities. So I'm just going to make a brief mention here and go on to the comparison:

· JVM selection

· The selection of the program to be analyzed

· CLASSPATH and Resource Path selection

To start the evaluation session, all three products require you to select the JVM, and we usually run the application on the JVM. Once you have chosen the JVM, you must specify the main class of your program, or the executable jar file, and what parameters to specify if your program wants parameters. Finally, setting up classpath for the evaluation session will usually also indicate the tools on your source layer. Figure 1 shows a typical session-time Configuration dialog box.

Figure 1.

Starting a program within the parser means generating, capturing, and observing large amounts of data, so all parsers contain different methods for controlling the flow of data, filtering on different standards and on the basis of each package. It can also be done using flexible formal expression type patterns such as java.util.* or jav*.