Letters

Moreover, on a technical level, I disagree with Don's assertion that it is difficult to codify a standard solution to this problem, and the article would have been improved had he taken more time to consider what can be done with XML Signature. To whit, the XML signature namespace includes an <Object> tag that allows the consumer of XML Signature technology to add whatever additional information is cogent to the context. The <Object> tag is a well known part of the specification that appears in its earliest examples. It is a simple matter to require (or at least recommend) that signatures created in a sign and encrypt scenario be created with an <Object> element that contains a <Recipient> element which, in turn, can contain an encoding of the intended recipient's public key certificate; thus taking the solution suggested by Don in Example 2(a). Had Don ever raised this issue with the XML Signature working group (which he has not done at the time of this writing), I for one would have provided the simple solution above, and I may have even added it to the Signature Scenarios document (http://www.w3.org/Signature/Drafts/PROP-xmldsig-faq-20000218/Overview.html).

To his credit, I notice that Don has raised this issue with the XML encryption group, where the issue properly resides. Unfortunately, I do not agree with the group's current decision not to address Don's point, but I am not in the XML encryption working group and am writing mainly to set the record straight about XML Signature. The XML Signature specification is a mature work nearing completion and easily capable of providing a solution (given above) for the surreptitious forwarding problem discussed in Don's article.

John Boyer
JBoyer@PureEdge.com

Healthcare Woes

Dear DDJ,

An acquaintance of mine was once a programmer for an unnamed port authority. This port authority was going through the transition from traditional stevadorage — brawny men shifting cargo in and out of ships — to containers. Labor productivity increased by a factor of perhaps as much as 400 at some points. The port authority was in the process of negotiating a labor buyout, and in an effort to demonstrate good faith, allowed the workers to essentially write their own ticket in all kinds of accounting issues. A bargaining unit as small as six individuals had its own contract, with its own distinctive terms, all of which had to be programmed. My acquaintance is a janitor's daughter — obviously, the port authority took some pains to find someone whose working-class credentials were impeccable. A massive software system, of something like a million lines, was dedicated to expressing the idea: "We are not trying to steal your job. We will buy you out at a fair price."

I suggest that the Health Insurance Portability and Accountability Act is to be seen in similar terms: a pragmatic buyout en route to a Canadian-style single-payer healthcare system. Our economy is going through very drastic changes as it computerizes. Jeremy Rifkin's conclusions (The End of Work, etc.) may be debatable, but his facts are undeniable. We are going to see a series of similar buyouts, necessary in the interests of social stability. As I write, in the wake of September 11, the federal government is in the process of buying out the airline industry and buying out New York City. Even before the bombing, both were in the process of being driven out of business by computerized communication systems, such as the Internet. Each buyout is going to involve a massive programming job of, in effect, describing the status quo ante bellum to form a basis for calculating compensation payments.

Andrew D. Todd
U46A8@WVNVM.WVNET.EDU

J2EE Cache and Pool

Dear DDJ,

I believe that Art Jolin, in his article "Can J2EE Manage Cache and Pool Memory?" (DDJ, October 2001), is mistaken when he says "The javadoc for WeakReference indicates that it can have its referent freed at any time, even if there is a strong reference to it somewhere." The whole idea of weak or soft references is that they merely do not prevent garbage collection of their referent. What it comes down to then is simply a matter of policy: That is, how eagerly or lazily the garbage collector deals with them. Art seems to be saying that using a weak reference allows referents to be garbage collected when they otherwise would not be, or that the referent can be set to Null even if there are strong references. I do not think that this is the case.

On a related point, Art notes that soft references are generally more useful than weak ones due to the policy differences. It may be of general interest that at Global Graphics, we use weak references in debug builds and soft references in release builds, as this makes debug builds garbage collect the referents more and so it tends to uncover bugs in the application reference handling. Sometimes with soft references you might only encounter garbage collected referents in extreme circumstances and so NullPointerException bugs can lurk in the code and manifest only rarely and obscurely.

Jason Trenouth
jason.trenouth@globalgraphics.com

Regex++

Dear DDJ,

I wanted to get a note off to you about John Maddock's article "Regular Expressions In C++" (DDJ, October 2001) and his regular expression library, Regex++. I am one of the users he graciously mentions in his article and a very pleased one at that. The Regex++ library solved a world of problems for me in a program I was writing at work. Not only that but John Maddock helped me a great deal via e-mail to get the library to compile and run on our Solaris 2.6 machines. He went so far as to create a make file just for my environment, which was a huge help for me. Anyone who is considering using the Regex++ library can be assured they will be impressed by the results.

Doug Farrell
dfarrell@grolier.com

DDJ