Interstage Studio User's Guide

6.2.5 Detecting and Correcting Problems

If there are errors, warnings, or other problems in Java files, JSP files or other source files, markers are set at those locations. Thus, problems can be checked from the icons displayed in the editor rulers and the highlighted displays in the source. A list of problems is also displayed in the Problems view. The problem content is displayed as marker information. Correct these locations as required.

Errors, warnings, and other problems are detected by various functions. The following functions detect problems:

• Java compiler
  The Java compiler not only checks for coding errors that violate Java specifications, but can also check for coding that may cause problems despite conforming to Java specifications.
  
  

• Validation
  This function checks whether or not a file or application unit conforms to conventions and so on.
  
  

• Interstage Java EE validator
  This function investigates an application's validity as a Java EE application.
  
  

• FindBugs
  This function identifies code that may contain bugs.

6.2.5.1 Java Compiler

The Java compiler not only checks for coding errors that violate Java specifications, but can also check for coding that may cause problems despite conforming to Java specifications.

The following categories can be checked:

• Code style

• Potential programming problems

• Name shadowing and conflicts

• Deprecated and restricted API

• Unnecessary code

• Generic types

• Annotations

More detailed check items belong to the above categories, and the check level can be customized. Customized settings can be entered from [Java] > [Compiler] on the preferences page, or from other preferences page under the preferences page. To customize settings for a specific project, use [Java Compiler] under the project properties.

6.2.5.2 Validation

The validators shown below are provided to validate files and applications. The validators can check in file units and project units.

Validator	Contents to be checked
HTML Syntax Validator	Checks the basic syntax of HTML files.
JavaScript Syntax Validator	Checks the JavaScript syntax described in HTML/JSP files.
JPA Validator	Checks the validity of an application as a JPA application.
JSP Syntax Validator	Converts a JSP file to Java code then checks for compile errors in that Java code, thereby checking the syntax of the JSP file.
JSP Content Validator	Checks the EL, directives, and so on of the JSP.
XML Validator	Checks that an XML file is in the correct format and checks its validity.

The validators run at the following times:

• When a file is saved
  Executed as a builder if ON is set for automatic build.
  
  

• When editing using an editor
  Validators that can check in file units also check during editing using an editor.
  
  

• When executing from a menu
  Validation can be performed by selecting a resource (file, project, or similar), then selecting [Validate] from the context menu.

Validation Settings

The validation operation can be customized using [Validation] on the Preferences page. To customize settings for a specific project, use [Validation] under the project properties.
Refer to the following concerning customization:

• Suspend all validators
  Specify this if you want to stop all validators temporarily.
  
  

• Manual/Build
  You can enable/disable each validator for both manual operation (executed by menu) and build.

6.2.5.3 Interstage Java EE Validator

The validity of an application as a Java EE application can be validated in archive file units, as shown below.

• Before deployment (default)
  The validity is checked before the application is deployed from Interstage Studio to the Interstage Application Server in order to check operation of the application, and so on.
  
  

• Execution from the menu
  The validity is checked when the project is selected and [Interstage Java EE Validator] > [Validate] is selected from the context menu. Use this method if you want to check the validity before application creation is completed.
  
  

• Build
  The Java EE validation function can be executed at build time. However, if ON is set for automatic build, all archive files are checked for validity as a Java EE application every time a file is saved, which is inefficient.
  Therefore, it is not recommended that developers use this method when developing separate Java EE modules. Use this method for group validation and execution when, for example, application build is performed as a batch.

Point

When an enterprise application project is checked, the modules it contains are also checked. If the workspace is used to create an enterprise application and also its constituent modules, and if the validity is checked at build time, avoid duplication by selecting only one or the other.

Interstage Java EE Validator Settings

The Interstage Java EE Validator operation can be customized using [Interstage Java EE Validator] on the preferences page. To customize settings for a specific project, use [Interstage Java EE Validator] under the project properties.
Perform customization with reference to the following:

• Check JSP file
  Checking the JSP duplicates the validation validator, and identifying problem locations is easier using the validation validator. Therefore, the default is to not check the JSP. However, if you want to perform a strict check for an application operating on an Interstage Application Server in order to use and check the Interstage Application Server JSP compiler, the JSP check can be used instead of the HTML/JSP syntax validator to validate the Java EE application.
  
  

• Execute pre-deploy
  This checks the validity before the application is deployed from the Servers view. Once the application structure is determined, and while at the stage of only correcting faults in the implementation part, for example, omit this check if there is little need to check the validity before checking application operation.
  
  

• Don't check at incremental build
  If the check is performed at build time, the default setting is to not perform the check for a incremental build. Deselect this item if you want to check in archive file units every time even for differential builds.

6.2.5.4 FindBugs

FindBugs can be used to identify code which may contain bugs as shown below.

• Execute from the menu
  To execute FindBugs, select the resource (project or file), then select [Find Bugs] > [Find Bugs] from the context menu.
  
  

• Build
  FindBugs can be executed at build time. (Execution of FindBugs at build time is not set as the default.)

Point

It is also possible to change the settings collectively to execute as builders by selecting multiple project and [Find Bugs] > [Turn on "Run FindBugs automatically"] from the context menu.

The detected problem will be displayed in the Problems View in the following format.

  <Warning priority> <Bug category> <Bug pattern> : <Message>

• Warning priority
  Represented by the initials of High, Medium, Low. Detection level can be customized in [Minimum priority to report].
  
  

• Bug category
  Represented by an abbreviation of bug category (one English letter). The bug category unit is a unit that can be specified to check or not check. For details on mapping of bug category and abbreviation, refer to "Check Contents".
  
  

• Bug pattern
  Represented by an abbreviation of bug pattern (a combination of numbers and letters). The operation check can be customized by listing in the filter file.

In addition, as listed below, views and perspectives for the purpose of displaying problems detected by FindBugs are also provided.

• FindBugs perspective
  This perspective is for correcting code for which the possibility of a bug has been detected. This perspective is comprised of the Bug Details view, the Bug Tree view, the Bug User Annotations view, and so on.
  
  

• Bug Details view
  This view displays detailed information concerning detected problems.
  The warning priority, bug category, problem location class, method name, field, source file name and line number, an overview of the problem, and detailed contents are displayed as detailed information.
  
  

• Bug Tree view
  This view displays the detected problems in a tree format.
  Tabs are assigned in project units in the Bug Tree view, and the detected problems are displayed in tree format within the tabs in bug pattern units. Details of a problem selected in the Bug Tree view are displayed in the Bug Details view. Alternatively, if the problem in the Bug Tree is double-clicked, the location that caused the problem is displayed in the Editor area in the same way as in the Problems view.
  
  

• Bug User Annotations view
  User annotations can be entered concerning each of the problems detected by FindBugs.
  As an annotation, a classification can be selected or any comment can be specified. In addition, the view displays the date and time the problem was detected.

Check Contents

In FindBugs, the checks shown below are performed.

Bug Category	Abbreviation	Overview
Performance	P	It is not necessarily a mistake, but it is possible that execution efficiency will worsen. For example, the following points are detected. Inefficient use of URL class Inefficient use of String class Inefficient use of valueOf method Inefficient use of boxing/ unboxing Field or method declaration that is not in use
Correctness	C	Obvious coding errors that resulted in unintended code by the developers. For example, the following points are detected. Misuse of equals method Obvious infinite loops Naming issues in fields, methods and so on Null pointers
Internationalization	I	Flaws exist in code that deals with Internationalization or locale. For example, the following points are detected. A method that keeps the Locale in the argument is not used
Multithreaded correctness	M	Flaws exist in code that deals with Threads, locks and volatiles.
Bad practice	B	Code that deviates from recommended or fundamental coding patterns. For example, the following points are detected. Exception handling Incorrect comparison of character strings Misuse of finalizer Use of equals method Confusing names of fields, methods and so on Serialization problems
Malicious code vulnerability	V	Code that is vulnerable to attacks from untrusted code. For example, the following points are detected. Possibility of internal expressions spilling Related to private or final (and so on) modifiers
Dodgy	D	Code that is easily misinterpreted, improper, or invites errors. For example, the following points are detected. Related to settings of values to variables Related to cast

The bug category units above can be customized to check or not check.

FindBugs Settings

The FindBugs operation can be customized using [FindBugs] on the preferences page. To customize settings for a specific project, use [FindBugs] under the project properties.
Perform customization with reference to the following:

• Minimum priority to report
  Problems with the specified detection level or greater are detected.
  
  

• Exclude filter files
  Bug detection is excluded by the settings of an added filter file.

For setup items that are specific to a project, refer to the following:

• Run FindBugs automatically
  Specify this option when performing FindBugs at build time.

Point

It is also possible to change the settings collectively to execute as builders by selecting multiple project and [Find Bugs] > [Turn on "Run FindBugs automatically"] from the context menu.

FindBugs Filter File Format

With FindBugs it is possible to control whether or not checked content is treated as a problem using the filter file. For example, if with FindBugs detects a problem but a code check proves that it is not actually a problem, the exclude filter file can be set so that in future it will not detect that as a problem.

The tags used by Filter File are explained below.

Tag	Attribute	Description
FindBugsFilter	-	Top level element of filter file.
Match	-	Element used to identify class.
	class	Specifies class name.
	classregex	Specifies class name as a regular expression.
BugCode	-	Element used to specify bug pattern abbreviations. The bug pattern abbreviation is the alphabet combination displayed third in the problem message.
	name	Separate each bug pattern abbreviation with a comma.
Priority	-	Element used to specify priority.
	value	Specify one of the following values. 1: High 2: Normal 3: Low
Method	-	Element used to specify method. The params attribute and returns attribute are not mandatory, but if specifying, both must be specified.
	name	Specifies method name.
	params	Separate each full qualified argument type name with a comma.
	returns	Separate each full qualified return value type name with a comma.
Or	-	Element that acts as an OR logical operator.

The following is an actual exclude filter file.

<?xml version="1.0" encoding="UTF-8"?>
<FindBugsFilter>
     <!-- Do not detect a problem related to ClassNotToBeAnalyzed class -->
     <Match class="com.foobar.ClassNotToBeAnalyzed" />

     <!-- Do not detect the following problems related to ClassWithSomeBugsMatched class
       DE : Exception is overlooked or ignored.
       UrF: A field that will not be referenced exists.
      -->
     <Match class="com.foobar.ClassWithSomeBugsMatched">
       <BugCode name="DE,UrF" />
     </Match>

     <!-- Do not detect SQL problems in any class -->
     <Match classregex=".*" >
       <BugCode name="SQL" />
     </Match>

     <!-- Do not detect field double-check problems for nonOverloadedMethod, frob or blat method of AnotherClass class -->
     <Match class="com.foobar.AnotherClass">
       <Or>
         <Method name="nonOverloadedMethod" />
         <Method name="frob" params="int,java.lang.String" returns="void" />
         <Method name="blat" params="" returns="boolean" />
       </Or>
       <BugCode name="DC" />
     </Match>

    <!-- Do not detect priority 2 (normal) problems in check item "substitution of meaningless local variables" for the someMethod of the MyClass class-->
    <Match class="com.foobar.MyClass">
      <Method name="someMethod"/>
      <BugCode name="DLS "/>
      <Priority value="2"/>
    </Match>

</FindBugsFilter>