October 21, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Java Language Integrity & Security: Fine Tuning Bytecodes

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

Limits of Scope

There are, of course, limits to the number of user defined names that you can change to a single character. You saw that in the case of class attributes you had to utilize the this pointer to differentiate scope. At some point, the scope conflicts cannot be resolved by using a single character name. In the following code, the method a contains two attributes, a and b. Because the attributes a and b are within the same scope, they must be unique names.

public void a(double amt , double bal) {

   double a = amt;
   double b = bal;

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

}

Returning to the example in Listing 6, the last holdout for the user-defined names are the parameters passed into the two methods. As you saw before when exploring the signature, each method has a single parameter and they both have a user-defined name, which is somewhat descriptive.

   public void a(int number)
   public void a(double bal)

It would be nice to define both of the parameters, number and bal, simply as a. But you can't; you have reached another limit of scope.

You run into a problem if you define both of these attributes as a, as in the following code.

   public void a(int a)
   public void a(double a)

In both these cases, you now have a conflict because each of the methods already has an attributes defined as a, and you obviously can't have two attributes with the same name. So, what do you do now? You probably guessed it; you use b, of course. When we get to the point where you have used as many as and bs as you can, you use c, and so on. The concept is elegantly simple; however, it gets very confusing because it is very hard to follow all of the as, bs, and cs—yet, that is the whole point.

Thus, to complete this example, you define the parameters as c and you end up with the code in Listing 7.

public class Performance {

   public static void main(String args[]) {

      a app = new a ();

      app.a(2001);
      app.a(3001.0);

      System.out.println();

   }
}

class a {

   private int a = 1001;

   public void a(int b) {

      int a = b;

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

   }

   public void a(double b) {

      double a = b;

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

   }
}

Listing 7: The Employee Class

Part of the Build Process

One of the questions that you might ask is that if these techniques are meant to make the code so hard to read, and thus maintain, why in the world would anyone want to employe them, because you will have to read and maintain the code? The beauty of this approach is that you always operate on the original, well-documented, human-readable, source code.

The elegance of this approach is that the techniques (basically a software tool) are always applied to the bytecodes that come out of the compiler and not the source code. Thus, as part of the process defined in Listing 1, the programmer always updates the source code, just as expected, and then the tool is applied to the bytecodes. For all intent and purposes, the alteration of the bytecodes is transparent to the programmer. It simply becomes part of the build process.

Conclusion

In this article, you began to explore how you can process the bytecodes produced by the compiler to help you improve performance, security, intellectual property protection, and readability issues. You have only skimmed the surface of these issues. As an academic exercise that can lead to some very good practical applications, you can actually decompile the bytecodes to see what the compiler is actually doing in its own right.

In next month's article, you will do just that and delve more deeply into understanding how the structure of bytecodes can help in the construction and testing phases of the software development process and how it affects the performance and security of an application.

References

  • www.sun.com
  • Fine Tuning Java Applications. Java Report, November 1999. Matt Weisfeld & Gabriel Torok.

About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, C#, and .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process, which is now in its second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.





Page 4 of 4



Comment and Contribute

 


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

 

 


Sitemap | Contact Us

Rocket Fuel