August 17, 2018
Hot Topics:

Java Language Integrity & Security: Fine Tuning Bytecodes

  • April 4, 2007
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

In Scope

Two of the issues mentioned earlier in the article were that of performance and the protection of intellectual property. These issues dovetail well into this discussion of code readability. The main point revolves around the statement made that creating descriptive attribute names make code more readable. This in itself probably can't be disputed; however, arguments can be made that creating descriptive attribute names is not necessarily the best for performance and the protection of intellectual property.

It is pretty easy to see that if you have 100 attribute names in your application, and each one averages 7 characters, you have to obtain storage for at least 700 characters. Yet, just by reducing the average number of characters to 3, you only need 300 characters. Obviously, you have a savings of over one half. This may seem trivial, and in many cases it is; however, for hardware with small memory footprints, memory usage like this can add up—in this example, you are only talking about 100 attributes.

You can even save more memory space if you take advantage of the concept of scope. Theoretically, from the perspective of memory usage, it would be nice if you could name every single variable as a single character. This has apparent limits. For starters, there are only 26 letters in the alphabet. So, you could not have named all of your 100 attributes using a single letter; you would run out of letters. In this case, you are fortunate because you can take advantage of the fact that only attributes with the same scope are required to have different names.

For example, in the Performance application, there is a class attribute named companyID, the Employee() method has an attribute named employeeNumber, and the Finance() method has an attribute named balance. All three of these attributes have totally separate scope. In fact, you could have named all three of the attributes companyID, or even simply a. Assume that you do name all of these attributes a. Although there would not be any compiler confusion with the attributes in the two methods, the class variable would lose the precedence battle with the tighter scope of the methods. Thus, you must get used to including the this pointer in your code as is done in Listing 4.

Note: The this pointer, unfortunately named perhaps, means that you use the scope of the object. Thus, the code this.a simply means to use the attribute a defined at the class level.

The code including the this pointer is highlighted in red.

public void Employee(int number) {

   int employeeNumber = number;
   System.out.println("nInside Employee ");
   System.out.println("companyID      = " + this.companyID);
   System.out.println("employeeNumber = " + employeeNumber);

public void Finance(double bal) {

   double balance = bal;

   System.out.println("nInside Finance");
   System.out.println("companyID = " + this.companyID);
   System.out.println("balance   = " + balance);

Listing 4: The Example Application Using the this Pointer

Using the this pointer makes the behavior of the code a bit more obvious, and it provides the groundwork for the concept we explore next. See how far you can go by naming everything you can in the application to the name a.

Obfuscating the Code

One of the ways that you can attempt to protect the code's intellectual property is to make the code harder to read. This is not the same as mangling the code or encrypting the code. Mangling or encryption implies that the code has to be decoded—perhaps with an algorithm. You can explore these concepts later; however, at this point you are just going to take a simple first step by making the code more difficult to follow. The act of making the code more difficult to read, or less clear, is sometimes called obfuscation. You can proceed in three steps.

The first step is to change all the attributes to a. This is accomplished in Listing 5.

public class Performance {

   public static void main(String args[]) {

      CompanyApp app = new CompanyApp ();




class CompanyApp {

   private int a = 1001;

   public void Employee(int number) {

      int a = number;

      System.out.println("nInside Employee");
      System.out.println("companyID      = " + this.a);
      System.out.println("employeeNumber = " + a);


   public void Finance(double bal) {

      double a = bal;

      System.out.println("nInside Finance");
      System.out.println("companyID = " + this.a);
      System.out.println("balance   = " + a);


Listing 5: The Example Application, Obfuscating the attribute names.

With this change, not only are all attributes a single character in length, they are all the same character. Besides savings pertaining to the length of the attributes, there are ramifications internally as to how the compiler stores and represents attributes—you will learn about this in later articles. Although this code may not be as human friendly as the previous version, it behaves exactly the same. When you run this example, you will get the output in Figure 2.

One interesting exercise you can perform here pertains to the use of the this pointer. If you take out the this pointer, you will get different results. For example, in the Finance() method, the following code will produce incorrect results because both lines will bind to the method variable—so the output for the companyID is incorrect.

   System.out.println("companyID = " + a);
   System.out.println("balance   = " + a);

As stated earlier, this exercise reinforces the concept of scope quite well. The use of scope is fundamental to object-oriented development, yet it is one of the most difficult concepts for beginning students to grasp. Even advanced developers find the variations are tricky at times. It is fortunate that not only is scope something you must understand; as you are finding, you can use it to your advantage.

Page 2 of 4

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