Globalyzer 5.1 Features

Locale-Sensitive Method enhancement

There are two new fields when configuring Locale-Sensitive Methods for Java: Class or Variable Type and Parameter Type(s) to Filter. If the Class or Variable Type is specified, then only method calls called via this class will be detected. If Parameter Type(s) to Filter is specified, then if one of the arguments is of the specified type, the Locale-Sensitive Method willnot be detected.

Let's say you want to detect toUpperCase calls for Java Strings, but not if the Locale is specified. You would configure:

    Pattern: toUpperCase
    Class or Variable Type: java.lang.String
    Parameter Type(s) to Filter: java.util.Locale

If Class or Variable Type is blank, then all toUpperCase calls will be detected (if not filtered by Parameter Type). If Parameter Type(s) to Filter is blank, then no subsequent filtering will take place. If multiple Parameter Type(s) are specified, then if one matches, filtering will take place.

Note that only one Class or Variable Type can be specified (which is different from String Method Patterns/Filters). This is because we want the help to be one for one, and we want the Parameter Type(s) to be for a particular method. Note also that before, patterns needed to be unique. Now class/pattern needs to be unique. So, for instance, you can specify:

    Pattern: getInstance
    Class or Variable Type: java.util.Collator

and:

    Pattern: getInstance
    Class or Variable Type: java.text.DateFormat

Each of these entries can have their own help and can specify different parameters to filter against.

One other change regarding Locale-Sensitive Methods is that the content of the reason field has changed. It used to contain the group name. Now it contains group name, method name, and class name formatted as below:

    group:method-class

If a class hasn't been specified:

    group:method

As part of upgrading your server, you will run a migration script to update the default Java rule set. When creating a new Java rule set, you will see the new rule configurations that make use of the new Class and Parameter fields. If you would like to upgrade an existing Java rule set, you need to do this group by group. Select your rule set, select Configure Locale-Sensitive Methods, click on a Group name to show the methods in that group, and then click on Add Locale-Sensitive Method Defaults (at the top of the page). This will bring in the new defaults, unchecked, for that group. You can check them to enable them and then delete the old rules. You will need to do this for each group.

Upgraded API

Added a new setSessionSettings() method that allows you to specify the following:

   data dictionary location (default is {userhome}/.globalyzer)
   whether or not to filter against the dictionary (default is true)
   set the scan timeout - the length of time to wait before determining
                                         that a file scan is taking too long (default is 120 seconds)

This would be called before login().

Also added new signatures for createScan() and createProjectScans() that allow you to specify some of the scan details that you can configure when using the Workbench. You can specify source file encoding, types to scan (Embedded Strings, Locale-Sensitive Methods, General Patterns, Static File References), and comment text.

Upgraded Lite

Passwords and Login Info in a .globalyzerrc

You can now set default login information for Globalyzer Lite by creating a .globalyzerrc file. It's now optional to specify login information within project definition files. With an exception that the Globalyzer Server URL is still required. The .globalyzerrc is not a required file. Settings within project definition files override those within the .globalyzerrc file. Note: If you are using a .globalyzerrc file, you still must set a Globalyzer Server URL within your project definition file(s). If the URL set in these file(s) does not match the URL set in your .globalyzerrc, Globalyzer Lite will refuse to scan the project. This helps to verify that your project is scanned using rule set information from the correct server.

Custom Scan Timeout

By default, Globalyzer skips files which take longer than 2 minutes to scan. You may now set the timeout duration yourself. It can be anywhere from a few seconds up to 5 minutes.

Additional Scan Customizations

You may now choose which issue types to scan for. For instance, you might wish to ignore all embedded string issues. Or to scan for only locale sensitive methods. In Lite 5.1, you may now specify custom values for Globalyzer comments. These comments tell Globalyzer to ignore a section of code, or to mark an issues as 'TODO'. One use for this feature is ignoring sections of test code within a project. For instance, given a C++ project you could change 'GLOBALYZER_START_IGNORE' to '#ifdef EMBEDDED_TEST' and 'GLOBALYZER_END_IGNORE' to '#endif // EMBEDDED_TEST'. Effectively ignoring test code within the project. You can specify the expected file encoding for each scan. No matter which encoding your source files are saved in, Globalyzer Lite will be able to scan them.

Globalyzer Lite Dictionary Settings

Globalyzer Lite now allows you to disable dictionary-based scanning. Dictionary based scanning helps Globalyzer filter out issues which don't contain English words. This setting is helpful if you want to see issues containing only non-english words. Lite allows you to specify a custom location to save its dictionary information to.