Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Letters to the Editor

JavaWorld.com, 08/29/03

  • Print
  • Feedback

Java Toolbox
"Why extends is Evil"
Allen Holub

Differentiating derivation and encapsulation



Allen,

I don't understand the difference between extension by derivation and extension by encapsulation. I think both are the same. To explain this, let me write the same Monitorable_Stack class in Listing 0.1 as an extension, and then please kindly explain the difference to me. 

35| class Monitorable_Stack extends Simple_Stack
36| {
37|     private int high_water_mark = 0;
38|


Nishant Kumar

Nishant, The main difference is that when you don't inherit methods then you have complete control over how the current class works, thereby isolating you from the fragile-base-class problems I discussed. For one thing, you don't have to worry about someone modifying the base class and adding a method that will effectively break the derived class if anyone uses it. Allen Holub


"More JSP Best Practices"
Dustin Marx

Zip up TLD files



Dustin,

There's a JavaServer Pages (JSP) best practice you didn't mention, and, if used, would obsolete one of the other practices you described.

In particular, you can package JSP tag libraries in their jar file with the TLD (Tag Library Descriptor) file in the META-INF directory. If taglib directives in the JSP pages use the Uniform Resource Identifier (URI) specified in the TLD, then you don't need to package the TLD for the tag library separately (you remove the need to create a tld subdirectory of WEB-INF), and the web.xml file does not have to specify the tag library.

David Karr

David, Thanks for the insightful comment. Packaging TLD files in a jar file (by placing them in the META-INF directory or in one of its subdirectories) with the Java handlers is a very slick way of delivering a complete custom tag package for use in a wide range of JSP applications. With the advent of JSTL (JavaServer Pages (JSP) Standard Tag Library), the tag libraries I mostly use now are the Struts tag libraries (the Jakarta implementation of JSTL) and other third-party tag libraries. Most of these, including Jakarta's JSTL (Standard Taglib) and Struts, deliver their TLD files individually. In these cases, I like to have my Ant script copy these TLD files from the central location where Struts and JSTL files are located into my war file's WEB-INF/tld directory. However, when I write my own custom tag libraries that other applications might readily use, I bundle these TLDs in a jar file with the tag handlers for a single packaged unit. I prefer to map the TLDs in my web.xml file regardless of the approach I take because it allows me to name the TLD reference I use in the JSP pages regardless of the actual URI. This is especially useful when I use XSLT (XSL (Extensible Stylesheet Language) Transformations) to transform my JSP documents and I need to know the URI in my namespace declarations to properly translate the source. It also allows me the flexibility of shorter or clearer URI references. Finally, I like listing them in a well-commented section in my web.xml so that other developers can quickly identify the custom tag libraries I am using in my Web application. Thanks again for mentioning the best practice of zipping TLD files up in the jar file. This practice definitely fits with the other best practices mentioned in my article. Dustin Marx


XHTML use



Dustin,

In your article, you advocate the use of JSP documents and XHTML as opposed to JSP pages and vanilla HTML. I agree that this is cleaner, but I am hampered because there doesn't seem to be a way to generate a <DOCTYPE> declaration for the resulting XHTML page without causing a JSP compile error.

DOCTYPES are necessary for generating XHTML pages and for standards-compatible Cascading Style Sheets (CSS) rendering on Internet Explorer 6.x browsers.

Tarun Ramakrishna Elankath

Tarun, Your message brings up an interesting point and allows me to clarify how I use XHTML in my JSP document development. My rendered HTML pages aren't fully XHTML-compatible because of the reason you cite and because many of the third-party custom tags I use do not produce XHTML-compatible tags anyway. An example of the latter case is a custom tag that creates list items with opening <li> tags, but without closing </li> tags. Instead of focusing on making my rendered HTML page XHTML compatible, I follow the XHTML specification's syntax rules and suggestions when writing my HTML as part of the original JSP document. This provides me and my fellow team members with a guide about how to write XML-compliant HTML (closing tags, empty body tags, using quotes for element attribute values, etc.). My focus in using XHTML during JSP development is to provide a standard for how to write XML-compliant HTML source so that my JSP document remains completely XML-compliant. This is useful in writing an empty tag like <br />. The XHTML documentation points out that the extra space allows even older browsers to correctly render this tag. Even though my JSP document is not an XHTML document, its HTML is completely XML-compatible and is therefore consistent with the JSP document's non-HTML portions. Dustin Marx


Java Design Patterns
"Make Your Apps Fly"
David Geary

On the Smalltalk defensive



David,

Your comments about Smalltalk were misinformed and wrong. You state:

Object-oriented design is sometimes at odds with performance. From a design standpoint, it's best to encapsulate everything in an object so you can treat those objects uniformly, reuse them, and extend them. Unfortunately, modeling everything as an object can be expensive performance-wise. A case-in-point is Smalltalk, which literally models everything as an object, as opposed to Java, which provides a mix of objects and intrinsic types. Today, Java is much more prevalent than Smalltalk, due in no small part to Java's better performance.


Java did not become more popular than Smalltalk because of performance. Smalltalk performance has not been an issue for years, and Smalltalk performance was much better than Java performance in Java's early years. Java won out for the same reason that Microsoft Windows won: marketing.

In fact, Smalltalk makes extensive use of the Flyweight pattern for performance reasons. In Smalltalk, for example, everything including numbers is an object. Numbers are represented as flyweight objects; there is only one instance of the number five in a Smalltalk VM. The everything-is-an-object philosophy leads to a consistent language with no need for all the kludges Java has had to introduce to get around the primitive object dichotomy.

  • Print
  • Feedback

Resources