Comprehensive physical examination tools for the Health4j-java project

Recently, I wrote an aggregator of Java code static analysis tools using my spare time. Three mainstream static analysis tools are integrated: pmd,checkstyle,findbugs. You can use the thousands of rule sets provided by these three tools to complete a physical examination of your project, along with a summary and email notification. The code is open source on GitHub, named health4j.

The purpose of developing this tool is to hope that it will constrain the normative code of its own. At the same time, guide yourself to use some of the industry-recognized "best practices" to ensure that at least your code is more "health". Another purpose of writing it is to continue my personal hobby-the "automation" tool.

The cleanliness and specification of the Code, the importance of a software project is self-evident. Especially those who have maintained the legacy code of others, I believe you are deeply touched. But do not say that others, even our own code, 35 months to look back on their own, and sometimes unintelligible. Of course, for code defects, it is more likely to be a time bomb that affects the robustness of a project. So I think the move is at least personally advantageous to me.

Introduction to Analysis Tools

The comparison of the three mainstream static code analysis tools in the Java World:

It is important to note that Checkstyle is primarily used to check code writing specifications. Pmd,findbugs is a very well-known flaw analysis tool. They collect a lot of check rules and bug patterns. Where PMD is used to analyze Java source code, and findbugs analysis of Java compiled bytecode, Jtest is a business tool, not currently integrated.

Design

Logical structure diagram:

The project currently provides the implementation of three analytical tools. Each tool is split into three parts: Envverifier (Environment authenticator), Commandinvoker (command executor), Reportextractor (Report extractor). The execution of each tool will trigger the execution of these three parts in sequence. And each tool is clustered into a single task for concurrent execution in the thread pool.

Each tool is run with a report file that outputs its own XML format. Depending on whether the Consolidator is enabled in the configuration file, you decide whether you need to parse and extract the report files that are output by each tool (Reportextractor) for aggregation by the following aggregator.

If you turn on the aggregator, extract the common data information from the report file output from each tool (abstract from the data information for each tool), and then generate an aggregated HTML report based on the given aggregation template.

If the notifier is turned on, the aggregated HTML will be sent to the target based on the notification's implementation (by default, a notification of the message).

Class Diagram Structure:

As can be seen from the code design diagram, each action has an interface abstraction corresponding to it. As a result, the implementation of only three tools is provided, but it still has good extensibility. Just provide the appropriate interface implementation, and define the required profile information, you can add more analysis tools. On the implementation of each tool, add the tool annotation in the diagram and indicate its name (Name property). Health4j at run time, it is automatically scanned to the implementation and added to the thread pool.

Service loader for Java SE

When developing Web projects, we usually introduce spring as an IOC container, so that we can isolate abstractions from specific implementations. But for a small standalone project, doing so seems a bit overkill. Fortunately, the JDK has provided the default implementation of the SPI (ServiceProvider Interface) since version 1.6. With it, you can implement the IOC without the "heavy" bean container of spring when you write some gadgets. The concrete approach is simple. It provides a serviceloader generic class. A configuration that implements a service that is typically defined as an interface or abstract class is loaded from a specified location.

For example, here are two service interfaces: Reportmerger,reportnotifier. We first create a folder named "Meta-inf.services" within a project's resource folder. Then create two configuration files inside. Each profile is a file name with the fully qualified name of the interface:

The content of each file is also exceptionally simple, and you only need to specify the fully qualified name of the provider (Implementation Class) of the Service interface:

Com.freedom.health4j.api.impl.common.DefaultMerger

So when we get the interface provider, we don't have to show that the instantiation process of the provider binds to the service. Example:

private static void merge (Reportinfo reportinfo) {        if (boolean.valueof (Commonconfig.getproperty (Constants.common _enable_merge_key)) {            serviceloader<reportmerger> Serviceloader = Serviceloader.load (ReportMerger.class );            iterator<reportmerger> mergeriterator = Serviceloader.iterator ();            if (!mergeriterator.hasnext ()) {                throw new RuntimeException ("Can not load service provider for Service:reportmerger" );            }            Reportmerger merger = Mergeriterator.next ();            Merger.setcommonconfig (commonconfig);            Merger.merge (Reportinfo);        }    }

Although this is not as powerful as a professional IOC container like spring. However, it is very simple and practical to develop small applications for some tool classes.

Use and integration

The tool can be executed as a standalone jar, or it can be built as a unix-like-service (see). Of course, as part of automation, we still want to have other triggering conditions other than human factors. Here, you can enumerate a few common trigger conditions:

• Time Trigger: Use Linux timed tasks to trigger at a specified time
  
• Event Trigger: Triggered in a hook of a code version control software such as VCs
  
• Continuous integration: Task triggering through build tools such as Maven/ant
  

Either way, the tool first needs to be published to the server hosted by the project's source code. And each tool owner's own set of rules, which are configurable, are located within the Release/conf folder.
Its running results are shown for example:

The development of many things has a similar history: from initial stubbornness to the final standard of compliance. Standards represent a common part of their interests, and if your team has not yet formed a unified code style, and has not yet realized that adopting best practices is the ultimate choice to avoid defects, then you need this tool. Of course, with this tool is only the first step, it is just a check that you perform the standard. The next step is the key: you need to sit down and discuss what is worth changing the rules for, which is the standard you want to form.

Project Address: https://github.com/yanghua/health4j

Comprehensive physical examination tools for the Health4j-java project