Letters to the Editor

J2EE Project Management

'J2EE project dangers!'

Humphrey Sheil

Does Java use pass-by-value or pass-by-reference?


I couldn't help but notice a glaring error in the symptoms section of Danger 1. You note that one of the symptoms of the given danger is "not knowing ... pass-by-reference semantics of Java." I hope that was a typo, as any seasoned Java developer knows that Java uses pass-by-value.


Tom, That wasn't a mistake. In Java all objects are allocated from the heap using the new operator, and variables that designate objects always hold references to (basically, addresses of) objects. That is similar to those objects in C++ that are allocated from the heap with the new operator and accessed through a pointer. When such variable is passed to a function, it is copied (say, to the stack), so technically you pass this address (reference, pointer) by value. However, when we say less formally that we "pass an object to a function," the object is not copied as the traditional use of "passing by value" might imply. But the function receives access to the original object and can change it -- as traditionally "passing by reference" implies. In less formal wording, by value and by reference may depend on the semantics of a programmer's intentions. Is he or she passing an object, or a reference to an object? More often than not, the intention is to make an object available to a method so that the method can use or change its fields, or call its methods. In this case, it seems fair to say that the object is passed by reference because the method receives a reference to the object. When I program in non-EJB Java, I always assume pass-by-reference semantics. That is, if I send an Object A into public void scrambleA(Object A) then A gets scrambled. I was not taught this type of pass-by-value semantics in college. On the other hand, value objects in the EJB world correspond to pass-by-value semantics perfectly. Humphrey Sheil

Danger #11: Don't design the application around the GUI


While your article was excellent insofar as the dangers that it depicts, I think you might need to reemphasize the most prevalent design-phase danger: becoming enamored with the technology, in this case Java and J2EE architecture, and forgetting what 90 percent of all IT applications do -- move and process data. J2EE architects must remember that successful applications are designed around the data, not around the GUI. If the purpose of the implementation is to merely entertain the user, then that logic does not apply. However, if the architect's intent is to accomplish some business-oriented purpose, then the GUI is secondary.

One of the most common mistakes I've seen in my 25 years of data processing is for novice designers and architects to begin with "Well ... we need a screen to do this, and we need a screen to do that," and thus relegate the data to a secondary role. Then, when the app is implemented -- or, hopefully, during user-acceptance testing -- the glaring holes in the data design become apparent and the developers go into the redesign phase. I have observed that most developers design the business logic around the presentation logic, where the presentation author makes requests of the business-logic designer to create or package the functionality based upon the presentation.

While this subtle differentiation might seem obvious to experienced application designers, J2EE is new, and with new technologies, there exists a strong tendency to proclaim that the design rules that have evolved over the past 40 years no longer apply. When client-server technology first evolved, those rules were ignored, resulting in failed projects, huge cost overruns, and increasing inception-to-implementation times. J2EE goes far to imprint these principles into the entire architecture. But designers require a good deal of discipline to forestall "seeing" the fruits of their labors until appropriate, and to spend their effort on the less dynamic tasks of data flow design and data architecture.


Stephen, Fair enough, but honestly I have not seen the problem you point out as a major danger on projects. On multidisciplinary projects I have seen problems with different timelines from the systems and creative teams cause overruns and integration issues (functionality with look and feel), but usually there is a yin and yang to GUI and backend. Without a good GUI, the backend is useless and vice versa. Humphrey Sheil

Pros and cons of using a build tool


I have been developing with J2EE developer for more than two and a half years now and generally agree with everything you say, except for this advice: Use a build tool.

I admit that a build tool that does everything for you, even deployment, is fine assistance and, later on, even essential. But in the beginning of a project, a build tool hides too much J2EE information from a developer.

In my case, I worked on a project that involved 20 persons. Only the project members who developed the build tool (Ant) were really familiar with J2EE deployment. The rest were not able to complete deployment without assistance and explanations!


Oliver, I disagree! I've seen the situation you describe in two settings:

  1. Only one team member truly understands how to do a build
  2. All team members have to become familiar with the build process

I'll take the second situation over the first one any day. All developers should be able to build the project. Tools like Ant are not as simple as they could be, but they're not that difficult either. Having a designated build master means having to ramp someone else up when that person leaves the team or takes a vacation. I feel that it's better to have the whole team up to speed on the build process instead of just one selected developer. Humphrey Sheil

Java Traps

'Dodge the traps hiding in the URLConnection class'

Michael Daconta

Voodoo programming


  1. Shouldn't OutputStreamWriter.close() automatically flush? Calling flush() before close() is akin to nulling variables in a class when the garbage collector will do this for you, which is voodoo programming (a phrase from a programmer who I highly respect).
  2. If the message you posted contained unicode characters that are not represented as more than 1 byte, then msg.length() would have been inaccurate. If you were to have a method that given a unicode string, would return the accurate length, what would that method be?

Dave Smiley

Dave, Regarding your first point: There is nothing in the documentation that states that an

OutputStream close()

method is guaranteed to flush. Here is the Javadoc documentation for



Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. The close() method of OutputStream does nothing.

In addition, since this is an abstract class, there is no guarantee that the subclasses'


method will flush first. To be honest, I did not bother checking whether that was the case. Calling


on an output stream is fairly harmless. All the characters I passed (even in unicode) were only a single byte. However, to answer your second question: it depends on the encoding. I'm sure the HTTP protocol specifies a specific encoding, and you must ensure that the request property is set accurately. Good observation. Mike Daconta

Wire Protocol

'Clean up your wire protocol with SOAP, Part 1'

Tarak Modi

How do you match a response to a request?


I really enjoyed your article on SOAP and look forward to the rest of the series. One question I had concerned matching up a response to a request. It seems like the only way to do that is to actually parse the node name to see if it is the same as the request node name with the additional suffix of Response, which seems a rather weak coupling. It seems more useful to have something like:

           <message>Hello John, how are you doing?</message>

Bill Siggelkow

Bill, That's a great point and something that never occurred to me! Thanks for sending it along. I'm glad you enjoyed the article and hope you will enjoy the rest of the series. Tarak Modi

Logging Systems

'Robust event logging with Syslog'

Nate Sammons

How does Syslog compare with Log4J?


Syslog sounds nice, but why should I use Syslog and not Log4J. Is Syslog better than Log4J? How is Syslog different?

Geert Mergan

Geert, First, I want to say that Log4J is, as far as I know, a good product. I think that Syslog has a simpler API for writing messages. In Log4J, you have to retrieve an instance of a


object before you can log, like this:

  Category cat = Category.getInstance("com.foo");
  cat.info("Here is a message");

With Syslog, you just call static methods:

  Syslog.info("Here is a message");

Categories in Log4J are roughly equivalent to channels in Syslog. They can both be used to route messages. I think Syslog's configurations are more flexible. With Syslog, you can modify a running configuration and ask it to write its configuration out to an XML file to be read in later. In addition, Syslog has more loggers. It includes loggers that write to output streams (like


), regular files, files that rotate before they grow to a certain size, and files that rotate every hour (or minute, week, or month). It also includes loggers that write to Java Message Service, Remote Method Invocation, databases, and to a logger that sends email (text or HTML). That being said, writing your own logger is as simple as implementing an interface, and common functionality is inherited from the base logger class that comes with Syslog. Syslog's log policies allow extremely fine-grained use. Let's say that you log everything on all channels at the


level or above. If you have problems with one particular object, you can add a logger at runtime that singles out that object -- by class name or a pattern of class names, which is good for selecting a package -- and logs everything coming from that object to a separate log. At their hearts, Log4J and Syslog want to do basically the same thing -- log messages in a flexible way and not interfere with coding and performance. Nate Sammons

XML Tutorial

'XML document processing in Java using XPath and XSLT'

André Tost

How do you use XPath to set the node's value?

André, I am a Java programmer currently working with XML. I really like the advantage that XPath provides over searching the DOM for a node. My problem: I am writing an API that provides setter and getter methods to different fields of a set of XML templates. Using the XPath for getting seems obvious, but is there an equivalent way to set the node's value?

Hugh McBride

Hugh, That's a good question. You could use XPath to locate the node where the new element needs to be inserted and then use the standard XML APIs to make the actual change. You can encapsulate both items into your API. However, please note that XPath only defines a way to find one or more nodes in a DOM tree. If you want to support setters, then you need to define a convention for how to deal with cases where you want to insert a new element, but the XPath statement returns multiple nodes. Where will the new element go? How do you update multiple nodes' contents? You have to make sure that for every node returned by XPath, there is a parameter indicating what change needs to happen. That can get pretty complex. For a more standards-based approach you could look at the XML Java Binding Specification -- aka Project Adelard. It is not final, and I have not looked at it yet, but it will give some Java bindings for XML documents, which may be of help to you. André Tost

JDK 1.4 Preview

'The magic of Merlin'

Vinay Aggarwal

Does C# stand a chance against Java?

Vinay, Thanks for giving such wonderful insight inside the next generation of Java. But is this version going to cater for generic types -- templates in C++? The addition of assertion is great; I'm tired of hearing C++ developers crow about Java's lack of a template feature. Now I wonder where this leaves C#. Do you think C# has got a chance against Java? Franklin

Franklin, I am afraid that Java has no plans for including generic types. As far as I remember, that proposal has been considered and rejected. Regarding your question about C# and Java, I do not think people shifted to Java because it provided any superior alternative to generic types or anything else. C# is a combination of VJ++, Visual Basic, Java, and all other Microsoft technologies. In my opinion C# would certainly make it easier to build Windows applications. I do not think it is going to make any difference to Java at all. People who were using VJ++ to make Windows-specific applications will move to C# because it will make their lives simpler. But all those developers using Java now will stick to Java. Those who use Java do so for its rich APIs and platform-neutral behavior; they are not going to sacrifice that. Only time will tell the rest of the story. If Microsoft is able to provide some advantages -- APIs or "Enterprise C# Beans" -- the community may shift toward it. Vinay Aggarwal

Mobile Computing

'Deliver cellular messages with SMS'

Sonal Bansal

How to improve synchronization

Sonal, Regarding your request for improvements to the synchronization solution, I have the following suggestions:

1 2 Page 1
Page 1 of 2