August 16, 2018
Hot Topics:

Reduce String Literal Overhead with Eclipse

  • October 29, 2008
  • By Scott Nelson
  • Send Email »
  • More Articles »

Tracking the Culprits with Eclipse

The key to this has been mentioned, which is to set the Non-externalized strings to Warning in compiler preferences.

Click here for a larger image.

Figure 1: Setting Non-externalized strings to Warning in Compiler Preferences

The result of changing this configuration is that String declarations can be quickly found in the Problems view:

Click here for a larger image.

Figure 2: Quickly Identify Potential String Expenses

Hiding the Obvious Exceptions

Okay, so now you can identify all the non-externalized String literals to reduce overhead. Of course, in Figure 2 the warnings are displayed for the externalized String literals at their point of declaration. Eclipse provides a notation to add which allows the properly constructed Strings to be ignored as a potential issue.

public static final String USER_ID   = "userId";    //$NON-NLS-1$
public static final String PASSWORD  = "pword";     //$NON-NLS-1$

The use of //$NON-NLS-1$ tells the compiler to ignore the first string literal in the line. Another obvious exception to the rule is strings used for logging. The obvious solution would be something like this:

catch(Exception e)
   logger.error("Unchecked exception in logoutPortalUser(): " + e);

In this particular example, it may seem that it would be more efficient to declare a static final at the class level. However, since the logger concatenates the string, there is no actual savings, so adding the //$NON-NLS-1$ notation is adequate.

Just as the logger concatenates the string, you frequently need to do so in your own logger statements, such as:

catch(Exception e)
   logger.error("Unchecked exception logging in "+userId+" with
                 company name of "+companyName + e);}

In this example, you have two strings on the line. This requires a double notation like this:

//$NON-NLS-1$    //$NON-NLS-2$

In some cases, it is cleaner to simply have multiple lines rather than multiple notations.

Cheating the Solution

Those of you with larceny in your hearts may be thinking to yourself "what is to prevent people from simply adding the notation without checking if the String is used elsewhere?" The answer is not technical in the sense of code, but is technical in the sense that people have tendencies based on thought processes known as meta-programs. Someone who is not contentious enough to use the notation properly is generally not going to think to use it improperly. Even though this is probably not 100% true, I have only seen someone cheat once. And, that is where the process of daily code reviews mentioned earlier comes into play; this is how I knew the cheat had been done. After discussing it with the developer, they were happy to apply their contentious cheating into contentious improvement of their code. A definite win-win.


The principle of Occam's razor leads you to understand that the simplest solution is often the correct one. In software development, it is usually the best one, and often the one that eludes both junior and senior developers. Using a compiler warning to find potential performance issues is a very simple approach. What is interesting about this particular approach is first that the problem is common enough that a method for locating it is built into the world's most popular Java IDE, and second that it is some commonly overlooked that the default setting is to ignore it.

About the Author

Scott Nelson is a Senior Principal Web Application Consultant with well over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. For information on how he can help with your web applications, please visit http://www.fywservices.com/ He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


Thanks for your registration, follow us on our social networks to keep up-to-date