Globalyzer 5 Java Rules

Introduction

Globalyzer 5 introduces new types of rules based on a improved, in-depth i18n parsing.

Say that you want to filter strings passed as parameters to a method called get, which is a fairly common method name. With Globalyzer 5, you can specify the class name on which the rule should be applied. Let's say the I18nUtil class and the UIUtil both have a 'get' method. You can specify a string filter method on get for variables of type I18nUtil and you can specify a string detection method for variables of type UIUtil. Static methods are also handled. You can also have an overarching get filter for all classes if necessary in your code, as opposed to listing all the class types on which a detection or a filter must apply.

User Interface

Globalyzer 5 Java allows for class names to be specified as part of the rules. The following UI shows how to configure a new String Method Filter for the smalljava illustrative rule set.

• Name: That the name of the rule. It could be something like i18n get
• Pattern: That is the pattern which would match the method name. It could be something as simple as get
• Class or Variable Type(s): This is a pattern which would match the class name. It could be something like company.project.util.I18nUtil
• Description: The description or the reason for this filter could be something like "I18nUtil get method string parameters do not need to be externalized into a resource bundle for i18n purposes"
• Help Page: The link to a more verbose help page which may indicate the context and the reason for the filter.

Note: The value of Class/Variable Type(s) is a string delimited list of fully qualified classes and types. If the field is empty, the methods are filtered/detected on all variables or classes accordingly.

Type of Rules

The first rules to be impacted are Java String Method Filters and Java String Method Detection rules. Passing a String parameter to a Java method has the added level of knowing the variable class name. Filtering on a method called "setText" will now allow to differentiate between classes or objects of different types with that method being invoked. This will make for better rules and finer results.

As Lingoport explores other possibilities, other rules and other programming languages will be covered.

Example

Code Snippet

import company.project.util.Dbg;  // A fully qualified class name
import company.project.ui.*; // Label is in the company.project.ui package.
 [...]
 Dbg dbg = Dbg.getInstance();
 Label lbl = new Label();
 [...]
 dbg.setText("Create User action taken.");
 [...]
 label.setText("Menu");

This snippet of code does have strings.

The class company.project.Dbg is a debug class and the text method puts the String parameter into a database for support purposes. That string is not visible to the end user. In that instance, the setText method on a variable of type company.project.util.Dbg should be filtered.

The variable lbl of class company.project.ui.Label represents a text area in the User Interface and the setText method passes a user visible string. The string Menu passed to this setText method should be flagged: It needs to be externalized out of the code into a resource bundle.

Rule

The String Method Filter rule would be configured the following way:

• Name: Debug setText
• Pattern: setText
• Class or Variable Type(s): company.project.util.Dbg
• Description: String parameters passed to the Debug setText must not be externalized and translated.
• Help Page: <blank>

The String Method Detection rule would be configured the following way:

• Name: User Interface Label setText
• Pattern: setText
• Class or Variable Type(s): company.project.ui.Label
• Description: String parameters passed to the Label setText method must be externalized and translated.
• Help Page: <blank>

Result

When the rules are applied:

• the string passed to the Dbg variable setText method is filtered out and does not show up as a candidate issue
• the string passed to the Label variable setText method is detected and does show up as a candidate issue