Intro
This blog contains brief outlook on a tool named JLin, that is embedded in SAP NetWeaver Developer Studio and used for static Java source code analysis. There are customers who actively use JLin during development and source code early quality assurance phase, but there are others who don't have JLin in their development toolbox - together with that, lack of SCN discussions regarding usage of JLin for source code quality analysis makes me think that either this tool is obvious and straightforward for Java developers in SAP world, or it is not very common in SAP developers community and undeservingly neglected and underestimated by Java developers. If you are a part of the first group and are already active users of JLin, further reading may not be exciting for you, but if you are interested in figuring out how you can leverage through using NWDS built-in features on the way of Java source code quality improvement, let's move forward...
JLin is an integral part of NWDS distribution: it is already equipped with pre-configured default set of checks and it doesn't require any extra infrastructure components for assessing source code, it is highly integrated with other NWDS/Eclipse tools, results processing and presentation (all tasks are performed by JLin purely within NWDS - which also means, the tool can be used for offline standalone analysis). All together, mentioned features make the tool a great choice for rapid analysis of Java source code that can be conducted right from NWDS in very few clicks.
It shall be noted that JLin is in no way a replacement for well-known, commonly used and mature static source code analysis products like SonarQube, FindBugs, PMD, Checkstyle and others, and shall not be matched against them. SonarQube and its equivalents provide complete solution and infrastructure for static source code analysis, that is focused on centralized management and governance of this process, and provisioning of sophisticated features which include (but not limit to) such functionality as central storage of source code check templates and source code inspection results, capabilities for historic analysis and visualization tools, extensibility of existing patterns and development of custom checks, support of variety of programming languages for which source code can be analyzed. This also means such tools shall be installed and properly configured before they can be effectively utilized - that, in its turn, requires some efforts. In contrast to this, JLin is a lightweight tool that comes with default check patterns (that can be enabled/disabled, but cannot be extended), it employs basic Eclipse based user interface and does not provide rich aggregated analysis and visualization capabilities, as well as it only supports analysis of code written in Java. But in many general cases, it can be used either completely out of the box or with minimum adjustment - as a consequence, its initial setup becomes a matter of few minutes.
Having written so, I shall encourage developers to differentiate use cases for JLin and dedicated general purpose static source code analysis tools mentioned earlier, and point out that JLin can be considered as a complementary tool for fast preliminary analysis of source code quality, it can be included as an optional step in a process of quality assurance of developed Java applications, followed by (preferably) mandatory extensive analysis of submitted development by means of static source code analysis infrastructure that is used across the organization.
JLin is described in details in SAP Help - refer to Testing Java Applications with JLin - SAP Composition Environment - SAP Library. Even though help materials for JLin are placed in SAP Composition Environment space, the tool is generic and can be used for vast majority of Java developments related to other areas, PI/PO being one of them.
On high level, process of JLin usage consists of following principal steps:
- (Optional) Define JLin initial (general) preferences and properties like optional export of results to an external file, priority threshold, etc.;
- (Optional) Define custom JLin variant containing selected checks from a list of checks shipped with NWDS and their priorities;
- Create JLin launch configuration for an assessed Java project using default or custom JLin variant;
- Run created JLin configuration;
- Review and analyze JLin tests results.
JLin initial preferences and variant configuration
A default JLin configuration already contains commonly used major checks for tests, but if it is required to enable or disable some checks, or change their priority, then in NWDS, go to menu Window > Preferences. In Preferences window, select Java > JLin:
Here, it is possible to check default variant configuration or create a custom one.
For a created variant, it is possible to customize general properties like results export to an XML file (which is helpful for further analysis of results produced by JLin, outside of NWDS, especially in case of further machine parsing and processing), priority threshold, etc..
Central aspect of JLin variant configuration is definitely selection of tests that form basis of JLin variant and scope of checks that will be applied to examined source code:
A set of JLin checks is shipped by SAP as a part of NWDS and cannot be extended. In case of uncertainty and unclarity regarding any specific check, it is possible to get description of test scope and useful explanatory notes (available from context menu of a check):
For selected checks, it is possible to adjust their priority based on individual estimation of severity and impact of issues detected in the source code and corresponding to those checks:
JLin tests launch configuration
If JLin launch configuration for the analyzed project hasn't been created yet, then in NWDS, go to menu Run > Run Configurations. In Run Configurations window, select JLin and create new launch configuration for it (either from a context menu or using corresponding button in a window). In a newly created JLin launch configuration, specify examined source code base (for example, Java project) and JLin variant (default or created on the previous step) that has to be used for analysis execution:
JLin tests execution and results analysis
After initial preferences are configured and launch configuration is prepared, we are ready to execute JLin checks, which can be done from the same window that was used to configure launch configuration on the previous step.
JLin outputs checks results and general statistics about executed JLin test to NWDS view Problems:
For every found issue JLin creates a problem marker, that can be explored in more details - corresponding Java resource can be opened and analyzed, Eclipse task can be created for that marker, as well as description of an issue (retrieved based on definition of a check that was not passed) can be viewed by selecting JLin test description from context menu of a respective selected marker:
Similarly to other problem markers in Eclipse, it is possible to use filters in Problems view in order to focus analysis on specific examined Java resources or issue types by selecting View menu > Configure Contents in Problems view and specifying required filter options:
As it can be seen from the above, just in few steps, we accomplished JLin configuration and conducted basic static source code analysis for a selected Java project - with absolutely no necessity in additional environment setup and/or external servers / Internet connection. As a result, already preliminary code check highlighted several issues and produced generic recommendations for their elimination, which can be addressed before developed source code reaches further quality assurance phases.