"I want my AOP!, Part 1"

Ramnivas Laddad

AOP plus OOP equals improved programming


Your article has opened a new dimension to me. Do you think AOP (aspect-oriented programming) is the add-on to object-oriented programming (OOP)? I think both AOP and OOP should join hands.


Nitin, I think AOP and OOP work together quite well. AOP adds modularization of crosscutting concern to OOP. The combined approach would use OOP for concern implementation and AOP to weave them together. For example, in case of logging, the interfaces and implementations for the logging mechanism itself would use OOP techniques (say, log4j). However, AOP best handles the invocation of logging operations, since logging is a crosscutting concern. Ramnivas Laddad

Programming languages help developers communicate more clearly


Just a quick comment on one sentence in an otherwise excellent article:

Programming methodologies and languages define the way we communicate with machines.

To be more precise, programming methodologies and languages define the way we communicate with people more so than with machines. This might seem like a trivial distinction, however, it is worth raising because it reflects a common misconception about code.

Programmers often choose technologies, languages, or design techniques based on how easily programmers can get the machine to do what they want. However, more important is the burden on the people who must read the code. Some languages like Perl just tickle developers to death by allowing them to cram a whole application into one line. Nevertheless, the effort saved in typing might cost many readers more effort and time in trying to understand the design. So programming languages and methodologies empower people to communicate with each other; communicating with the machine is really secondary.

The reason object-oriented programming succeeds is because it allows us to express software design in a way that more naturally reflects the way we think and use natural language. AOP's success will depend largely on these human factors. Will AOP code prove easy to understand and more naturally reflect the way we think and communicate? Perhaps. Time will tell.

Juan Osuna

Juan, I agree with you: programming methodologies and languages do define the way people communicate with each other in the system context. Programmer-machine interaction resembles programmer-programmer interaction. The way I approach it, programming languages and methodologies allow us to express our intentions to machines in certain ways. The more closely the expressions match intentions, the easier the programmer-machine and programmer-programmer interactions. Perl, as you noted, is a good opposite example: chaotic programmer-machine interaction and chaotic programmer-programmer interaction. Indeed, AOP's success will depend on human factors. The current programming methodologies and languages are just too hard. The problem: convoluted mappings of requirements/intentions to implementation expressions. Ramnivas Laddad

"Mix protocols transparently in Web applications"

Steve Ditlinger

Will Struts support protocol mixing?


I have struggled with this problem, and the way you stepped through your thought process was superb and enlightening. I do have several comments:

  1. Will this functionality be proposed in Struts? It seems a natural fit as you described.
  2. Are there any efforts to make such convenient use of HTTPS part of the servlet spec itself?
  3. I wanted to take a similar approach for redirecting to a login page when using form-based authentication (using BEA WebLogic Server 6.1). However, I could not get the "redirect me to HTTPS" behavior, only the frustrating WebLogic page. How do I achieve the redirect behavior without abandoning the form-based authentication?


Bill, In regards to your questions:

  1. I helped write a Struts extension that mixes protocols and a little more. In our extension, all link and form tags determine the security requirement of their referenced actions and create the link as HTTPS or HTTP accordingly. This further minimizes the number of actual redirects. Our developer group posted it to the struts-user mail list, and a few people are using it. I will cover the extension in a future JavaWorld article. You can find more information at http://struts.ditlinger.com.
  2. I have not heard of any efforts to make HTTPS part of the servlet specification.
  3. Our developer group used this solution in Struts (using the solution presented in my article) with container-managed, form-based authentication on BEA WebLogic Server 6.1. We specify the login form page as secure using the pageScheme tag.

Steve Ditlinger

Is the redirect approach really secure?


Three comments:

  1. The data is not really protected because it transmits using HTTP in the first pass before a redirect.
  2. It does not work with post data that will exceed the query string-length limitation.
  3. It induces performance hits with an additional request for each redirect.


Hope, You hit upon the source of much debate within our group. To answer your three criticisms: you're right, unless you specify the page you post from as secure using the pageScheme tag or some other mechanism. This seems standard practice on most Websites for login pages, if only to reassure people with the lock icon at the browser's bottom -- even though this does not mean the data will post securely. If the page itself is secure, in our group's scheme, no redirect is required to post securely. In an extension our group wrote to Struts, we actually added logic that determines if the post action is secure (HTTPS) or not, and generates the post URL accordingly. This makes the redirect unnecessary even if you do not specify the form page as secure. Steve Ditlinger

"JSP best practices"

Dustin Marx

Should we sacrifice performance for reusability and maintainability?


Academics repeatedly ignore one factor in Webpage design: the physical I/O (input/output) overhead involved in including a number of classes/structures in your JSP (JavaSever Page) document/application can be quite considerable. For example, a server can read a single page with zero includes from a disk and dump it onto the TCP line in 10 milliseconds. This overhead increases if a document is segmented into innumerable includes, custom tags, classes, and beans. There must be some point where the I/O overhead becomes too much. What do you think?

Ron Boles

Ron, You make an excellent point. While factoring common parts of a page into external pieces and using templates (that typically use an inclusion mechanism) are both best practices from a maintainability and reusability standpoint, they do involve more overhead. I also remember some early Web containers experiencing difficulty in serving pages made up of too many pieces. While my article focused mainly on reusability and maintainability, sometimes performance (or lack thereof) might require approaches directly contrary to those best practices. This situation resembles relational database design: we work to normalize our entities as much as possible, but sometimes we're forced to denormalize for performance reasons. I'm not sure how high the number of includes has to be before they threaten performance. That probably depends largely on the Web container being used and definitely on the project's performance requirements. I design JSPs according to the best practices described in my article, with the plan in the back of my mind to potentially remove some of these constructs if performance is too slow. Fortunately, I have worked on projects where the performance requirements have always been satisfied, even when I employed all those JSP best practices. Again, my JSP process resembles my process for normalizing and denormalizing a database: I try to make the design as modular (normal for database) as I can, but I'm prepared to make it less modular (denormalize for database) if necessary for satisfactory performance. Dustin Marx

Java 101

"Classes within classes"

Jeff Friesen

What happens when you can't remove a listener from an object dismissed from a UI?


My question regards anonymous inner classes and their use with ActionListener attached to Swing components. As you mention in your article, the use of anonymous inner classes for UI (user interface) work is quite widespread, but I worry about locked object references. When adding a listener to an object, won't the object stay alive (i.e., not be marked for garbage collection) because a listener is still attached? If the listener is defined within the addXXXListener() method call, sometimes you can't remove the listener when the object is dismissed from the UI -- so what happens? Perhaps this example might help you understand my question: I have a panel with two buttons on it. One button closes the panel, and the other performs some function that leaves the panel open. If I add anonymous action listeners to the buttons, as below, I can code the action listener on the Close button to remove itself as a listener from within the listener body. But how can I remove the other listener? Or does it matter -- will the panel closure prove enough to remove the anonymous listeners and mark everything for garbage collection? Abbreviated example code:

buttonA.addActionListener(new ActionListener()
  public void actionPerformed(ActionEvent e)
    // leaves the panel open
buttonB.addActionListener(new Acti


Ian, If an object contains references to other objects and becomes unreachable, that containing object and its contained objects (provided no other references to the contained objects exist, apart from the containing object's references) will be garbage collected. That means the panel containing object- and the listener-contained objects in your program will be garbage collected (provided no references to the listener objects exist, apart from those references contained in the panel object). This behavior will happen with Sun's Java 2 Platform, Standard Edition (J2SE) 1.4 JVM, at least. For proof, compile and run the following source code to the CC (Composite Cleanup) application using the aforementioned JVM:

// CC.java
// Composite Cleanup
class Global
   static boolean bCollected = false;
class A
      System.out.println ("A object created");
   public void finalize ()
      System.out.println ("A object finalized");
class B
      A a = new A ();
      System.out.println ("B object created");
   public void finalize ()
      Global.bCollected = true;
      System.out.println ("B object finalized");
class CC
   public static void main (String [] args)
     new B ();
     while (!Global.bCollected)
        System.gc ();
     System.out.println ("Bye");

When I ran this code, I obtained the following output:

A object created
B object created
B object finalized
A object finalized

The output shows that the



object is finalized prior to the



object being finalized. Jeff Friesen

"UI design with Tiles and Struts"

Prakash Malani

Do the solutions work with the latest Struts version?


I have two questions:

  1. We're currently at Solution 5, and we're already using Struts. Will Solutions 6 and 7 work with Struts 1.0, or is 1.1 required?
  2. We're using a StandardLayout.jsp to control our layout. Using Solution 6, how does this layout or JSP (JavaServer Page) get mapped? I don't see any reference to the JSP defining the header, footer, and body sections in the TileDefinitions.xml file. Therefore, how is the layout controlled using Solutions 6 and 7?


John, Regarding your first question: Solutions 6 and 7 work with version 1.0. They should also work with the current version, 1.0.1. Struts 1.1 has not been released yet. Regarding your second question: The layout gets mapped as a path attribute of the definition tag. Suppose you have a page called


That would translate into a definition called


using path


. For example, in the


file, we can define:

<definition name="HomeDef" path="/StandardLayout.jsp">

The header, footer, and body information goes inside the


tag. For example, in the


file, we can define:

<definition name="HomeDef" path="/StandardLayout.jsp">
         <put name="header" value="/header.jsp"/>
         <put name="footer" value="/footer.jsp"/>
         <put name="body" value="/HomeBody.jsp"/>

If you are already using Solution 5, moving to Solutions 6 and 7 should prove relatively painless. Prakash Malani

"Take the fast track to text generation"

Leon Messerschmidt

Template engines vs. JSPs


I did not understand what advantages the templates had over JSP (JavaServer Pages). The HTML example looked similar to JSP. Why does "the clear separation" you mention in your final paragraph apply more to templates than to JSP?


Paul, Although you can and should design a JSP system with clear separation, the system does not absolutely enforce the separation. If you use JSPs in a well-disciplined environment, your JSP and template views resemble each other. Unfortunately, many IT projects tend to run into tight deadlines, tempting developers to take shortcuts and insert business logic into JSPs. That is a very dangerous practice, especially for large or long-term projects. Template engines won't allow you to insert source code directly into a template, thus removing the temptation to sacrifice design for time. Templates also allow a better security level: Because everything is available to a JSP, sensitive information could possibly leak. With a template engine, only objects explicitly added to the context are available. If sensitive information isn't available in the first place, it cannot leak. Conclusion: Template engines enforce disciplined development, whereas JSPs require you to discipline yourself. For more information about templates versus other technologies, I refer you to the essay "You Make the Decision," by Jon Stevens (Apache Software Foundation). He was one of the founding members of Velocity; you might find the essay biased, but useful nonetheless. Leon Messerschmidt