Analyzing application code

• Code analyzer
• Prerequisites
• Procedure
• Examples for standard error and standard output streams
• Controlling the Java package list for binary analysis
• Results
• Current limitations
• What to do next

Code analyzer

The code analyzer collects static data from the application code of your Java monolithic applications that is used as input to the AI engine, which generates partition recommendations. This static data is also required as input to the binary instrumenter, which collects runtime data from your deployed applications. As the code analyzer scans the Java code, it generates four files. The JSON files contain metadata about the scanned classes and configuration for the binary instrumenter. The metadata includes information such as class names, their typed member attributes, constructors, methods with input arguments and return types, and source file locations of the classes.

The code analyzer can also instrument the source code of your Java monolithic applications so that runtime traces are collected when these applications run. The code analyzer scans all the Java classes of an application to insert instrumentation statements in the form of System.err.println("Entering...") and System.err.println("Exiting...") in all the class methods, including constructors. After the completion of code instrumentation with the code analyzer, rebuild and redeploy the Java monolithic application.

Source code instrumentation is a deprecated feature of the code analyzer. The binary instrumenter is the recommended option for collection of runtime traces while running business use cases, eliminating the need to rebuild and redeploy the Java monolithic application.

Prerequisites

Ensure to meet the system requirements.

Procedure

1. Put the binary archive file of your Java monolithic application in a directory structure.

   Valid Java archive file formats include .cba, .class, .ear, .eba, .jar, and .war. Also valid are .rar and .zip files that contain the Java archive binary files.

2. Run the code analyzer against the binary file of your application.

   Run the analyze command. To get command help, add the -h option.

   mono2micro analyze -a <binary-file-path>

   The following information explains the syntax for the command:

   • The <binary-file-path> variable is the path name for the binary file of the application to be analyzed. By default, the analyze command creates a directory called binary-file-mono2micro on the user working directory with several JSON files.

     You can add the -o option to specify the output directory path for the generated JSON files. The user that runs the code analyzer must have read and write access to the /<output-dir-path>/ directory.

     mono2micro analyze -a <binary-file-path> -o <output-dir-path>

   • You can generate configuration for the binary instrumenter that sends the traces to the standard output stream. By default, the binary instrumenter instruments your Java code with System.err.println() statements for generating IBM Mono2Micro runtime traces in the standard error stream. Setting the --instrumentation-target option to the out value also applies to the source instrumentation if the mono2micro instrument command was used.

Examples for standard error and standard output streams

For the standard error stream, run the following command:

mono2micro analyze -a /apps/daytrader-ee7.ear

For the standard output stream, run the following command:

mono2micro analyze -a /apps/daytrader-ee7.ear --instrumentation-target out

Controlling the Java package list for binary analysis

The binary analyzer inspects all the Java classes within the binary file except the packages excluded by default. You can check the default list of excluded packages with the -h option.

com.test.app,org.xyz.lib,edu.abc

Results

On successful completion of the analysis, if an output directory is not specified, the code analyzer creates a directory called binary-file-mono2micro on the user working directory with multiple files, where binary-file is the name of the analyzed Java binary file. For example, if the binary file is daytrader-ee7.ear, the code analyzer creates a directory with the name daytrader-ee7-mono2micro in the user working directory. If the output option is specified, the JSON files are placed in the provided directory.

After analysis, the directory contains the following files:

• symTable.json
• refTable.json
• instrumenter-config.json
• recommender-config.properties

The symTable.json and refTable.json files contain metadata about scanned classes such as their names, locations, attribute names, constructors, and methods. The instrumenter-config.json file provides configuration for the binary instrumenter. The recommender-config.properties file specifies the location of your Java application archive on disk and the packages that were excluded or included during the analysis.

If source instrumentation was enabled on the code analyzer, the peer directory also contains a copy of the source code that is instrumented with System.err.println() statements that you use later to generate IBM Mono2Micro runtime traces.

The code analyzer instrumentation never prints the value of any variables of your application. The purpose of the instrumentation is to record the temporal flows through various methods and constructors of classes, and not the values of any variables during run time.

Current limitations

• When you compile code instrumented by the code analyzer, you might encounter the unreachable code compilation error. In some edge cases, the code analyzer instrumentation might insert instrumentation statements, which the Java compiler detects as unreachable.

  To get past the problem, remove or comment out these unreachable statements. Their removal does not impact the generation of runtime traces in any way.

• When you run the code analyzer, you might encounter an out of memory error from the Java process. To resolve the problem, set the --java-opts environment variable by specifying a large maximum heap size as the value.

  For example, to specify a maximum Java heap size of 512 megabytes, run either of the following commands.

  mono2micro analyze -s <src-dir-path>  --java-opts "-Xmx512m"

  mono2micro instrument -s <src-dir-path>  --java-opts "-Xmx512m"

• When the binary analyzer finds more than one Java class with the same name and same package name, it analyzes the first one identified and ignores the others with the exact same name and same package name. Duplicate names can occur if the same class is packaged in multiple binary files within the binary archive. In this case, a warning is logged to report the duplicates found. For most cases, this is not a problem, especially if the found classes are identical. However, it can be a problem if the found classes have differences in their structure.

What to do next

If you want to get partitioning recommendations based on the business logic in the application, run your Java monolithic applications with instrumentation to generate runtime trace files. If instead you want to get recommendations quicker, based purely on the static analysis of your application, check the collected data and then run the AI engine. You use information from the code analyzer, and optionally the binary instrumenter and the use case recorder, as input to the AI engine, which generates partition recommendations. It is important to keep your Java application archive file in the same location on disk so that the AI engine can analyze it further during the partition recommendation step.

If you chose to collect runtime trace files through source instrumentation, after the code analyzer successfully completes the instrumentation process, you can build and deploy the instrumented application in nonproduction but representative environments. Follow the exact process that you use for building and deploying the original application. Depending on the environments, the applications and their instrumented versions can be on bare metal machines, virtual machines, or containers.