July, 2003

The Australian is again reporting on various attempts to pass bills mandating open source software (this link will work for a few days.)

The meat of the proposed South Australian bill is this wording:

A public authority must, in making a decision about the procurement of computer software for its operations, have regard to the principle that, wherever practicable, a public authority should use open source software in preference to proprietary software.

Predictably, Microsoft is opposed to this bill, and gives many emotionally-charged counter arguments via its public relations consultants. The worst of these arguments would have to be that such a bill would “limit choice”.

If “limiting choice” is so evil, why isn’t Microsoft kicking up a fuss every time a government tender goes out asking for systems to be compatible with Word or Excel file formats?

Of itself, “limiting choice” is neither good nor bad. Organisations do it all the time, in matters as diverse as exclusive agreements with courier companies, setting performance goals for sales executives and requiring that all company helicopter travel be pre-approved by the board.

If the South Australian government decides the benefits of a pro-Open Source policy are so pervasive and worthwhile that they should legislate it, then that is what they should do. It is equivalent to a company putting a pro-Open Source policy into its company articles—a bit strange, but hardly protectionist¹ and certainly not anti-free-world.

linuxsa.org.au is tracking the progress of the bill.

¹ To large U.S. companies who preach the wonder of free trade to governments of the world I say, “Bah! Come back when George W. Bush stops protecting US agriculture.” In case anybody thinks the US is a capiltalist country, I direct them to the EWG Farm Subsidy Database.

Some notes from O’Reilly ONLamp about BitTorrent’s Design. BitTorrent is a slick, non-commercial P2P file downloading network, in vogue among techie-folk at the moment.

Article high-lights:

• BitTorrent was first written in Python, and is being ported to other languages: Java, Perl, C, and C++.

• The design principle of “idempotence”—something I use regularly, but without the fancy name.

• BitTorrent’s author, Bram Cohen, calls his code “maintainable”, though the article’s write notes “while [BitTorrent is] written in very clear Python, the magic isn’t easy to grasp.” :)

For something this complex, implementing in Python first is attractive. Python is a good for experimentation, something that would have been important in BitTorrent’s early days. I can imagine that each new version of BitTorrent will be built and tested in Python first.

Meanwhile, because Bram Cohen was careful to define BitTorrent’s wire-protocol, implementations in other languages are appearing. Lesson: when writing a product, define and document any inter-program protocols, separate from the API.

ONLamp have a few other Python Articles.

via the Daily Python URL for July 21.

Sometime last week, my blog’s Berkely db files for comments became corrupt. The symptom was that visitors could not see the text of comments.

A quick flick through the Moveable Type support forums confirmed that Berkeley db corruption is a common problem, and that it often affects comments. I suspect this bug surfaces when two people attempt to modify a Berkeley db file concurrently, though it may also be something obscure inside Moveable Type too.

To cut a long story short, I decided to ditch Berkely db and use MySQL instead. The upgrade (instructions) was painless, taking 15 minutes in total. My web host already had MySQL installed, so the biggest trick was figuring out that the mt-db2sql.cgi script wasn’t in the 2.63-Full version of Moveable Type, and I had to download 2.64-Upgrade.

I managed to save just 26 of 122 comments. I am annoyed at losing thoughtful and humorous remarks from people that I know only online—Simon and Mats particularly come to mind.

In other news, the post that you are reading is this blog’s 100th. I was going to write a navel gazing piece about the wonders of blogging— how it has put me in touch with other technical folk around the world, educated me about new programming techniques, improved my writing skills and generally been a force for the greater common good. Instead, I offer my blog this thought:

“Happy 100, Cardboard Nu. Now don’t stuff up again, or I’m rebraining you with bloxsom.”

There are three main ways to put comments into JSP files: HTML comments, JSP “hidden comments” and Java comments.

HTML comments (reference)

<!- – This is an HTML comment – ->

The JSP engine will place HTML comments in the data stream sent to the user’s browser. This makes them useful for debugging, but they do take up bandwidth and are visible to users who select View/Source in their browser.

JSP hidden comments (reference)

<- – This is a JSP hidden comment – ->

Update: I had written the wrong syntax for JSP hidden comments. The above syntax is correct.

The JSP engine does not process the contents of hidden comments. They are useful for documenting as well as commenting-out sections of the JSP.

Java comments

<% /* This is a Java comment */ %>

Using both Java comments and JSP hidden comments requires some care. Java comments can be placed inside hidden comments, but hidden comments cannot be placed inside Java comments, because the ”>” part of the closing ”- ->” would terminate the Java block. ¹

In my JSPs I default to using hidden comments, unless there is a good reason to use one of the other two. A simple hidden comment is almost always the best choice.

Sun’s Code Conventions for the JavaServer Pages Technology Version 1.x Language has more to say on this topic.

¹ Your mileage may vary. While using WebSphere Application Server v4, I once mis-typed the end of a JSP hidden comment as ”- >” instead of ” -%>”. WebSphere placed the entire JSP starting from the end of the comment onto the outgoing data stream without processing it, and the browser ended up receiving the JSP tags. It took a good hour to figure out what was happening, and why.

Installed another Gentoo Linux box at home this week. The box is only a 233MHz PII so the install was quite slow.

I am very pleased with the result, and will be using it as a firewall and Samba server.

Matrix Ping Pong

It’s links like this that remind me what the ‘net is all about.

From the The Soporific Manifesto:

Q: What can you brush your teeth with, sit on, and telephone people with?
A: A toothbrush, a chair and a telephone.

You gotta love convergence.

Here is a truly educational song for all us aspiring GUI programmers. An excerpt:

Model View, Model View, Model View Controller
MVC‘s the paradigm for factoring your code,
into functional segments so your brain does not explode.
To achieve reusability you gotta keep those boundaries clean,
Model on the one side, View on the other, the Controller’s in between.

Model View — It’s got three layers like Oreos do.
Model View creamy Controller

And so it goes on.

via “Chris Winters“http://www.cwinters.com/News/show/?news_id=972.

Mr Ed brings us Hacknot. It advertises itself as “links, articles and news for disciplined developers.” Judging by the dates, the site is just two weeks old.

Particularly enjoyed the article Corporate Pimps—Dealing with Technical Recruiters. Mr Ed says:

I hate recruiters so damned much you wouldn’t believe it. In my mind, they are on an ethical par with used car salesmen, real estate agents and other occupations that work on a commission basis. The very title “Technical Recruiter” is an oxymoron, with the emphasis on moron.

A couple of days ago, Hani wrote an entry about on the topic of my Too Many EJBs post. Hani had a couple of good points and a few really bad ones.¹ The good points were that I need to ‘join the dots’ in the argument between the list of pros and cons and the article’s conclusion, that I should quantify the meaning behind “a LOT” and that I should explain what “eat memory and CPU cycles for no discernable benefit” means.

I’ve worked on two large J2EE systems. The current one has more than a million lines of source—1.5 million with generated code—and 500 EJBs distributed over twenty or so subsystems. Both this system and the one I worked on previously were designed similarly:

• Servlets make calls to Stateless Session EJBs designated as “Use Case Controllers”.
• The Use Case Controllers call a second tier of Stateless Session EJBs.
• The second tier manipulate data through CMP Entity EJBs or another layer of Stateless Session beans that access files or external systems.²

I know of several other large J2EE systems designed similarly, and none that are very different. But your mileage may vary.

Joining The Dots

Here I explain how I moved from the list of pros and cons to the conclusion that only one EJB per subsystem is required. The ‘first EJB’ is the Use Case Controller EJB that provides access to the subsystem. The “more EJBs” are the ones behind that that actually do the work.

The first part of this argument was that all the advantages of using EJBs are gained with this first EJB:

If you know of additional benefits, please leave a comment.

The second part of the argument was that the disadvantages accrue with each and every EJB:

What “a LOT” Means

I was surprised that anybody who has used EJBs would want this spelled out, but here goes:

• An EJB takes a LOT more effort to implement than a standard Java object. The “LOT” refers to the two additional interfaces, multiple configuration file entries. and plethora of rules as to what you may or may not do in an EJB or a class called by an EJB.

• Any EJB takes a LOT more effort to use than a standard Java object. Mostly means that I despise PortableRemoteObject. I have written about this before, though Charles does a more thorough job than I. It also refers to the jumping through hoops to get an object reference, remembering that the parameters may (or may not) be serialized, being careful with runtime exceptions and taking any transactional or access-intent set in the configuration files into consideration.

• Any call to an EJB takes a LOT longer than a call to a standard Java object. On my EJB container of choice, EJBs have between four and six generated support classes. At runtime, a method invocation on an EJB will traverse at least two of these classes. These support classes make calls to the container support libraries to, at a minimum, activate and deactivate the EJB. The container I use serialises and deserialises each and every parameter, regardless of whether the target EJB is in the same container or not. Compared to making a simple Java method invocation on a real Java object, an EJB method invocation takes a long time.

Eating Memory and CPU Cycles for No Discenerable Benefit

The commercial EJB containers I have used take thirty or forty seconds to come up with only a single EJB deployed. Some of this is initialising Servlet and EJB containers and bringing up essential services like JNDI. The more EJBs deployed, the longer it takes. The application I’m working on takes at least five minutes before it’s good to go.⁴ At this point, it has consumed 600,000,000,000 CPU cycles and 150,000k of memory, and it still hasn’t done anything useful. Running in development, memory usage levels out at about 250Mb, not much of which can be paged out because of the JVM‘s garbage collection.

Of course, this is a big app, and it requires considerable resources. But with fewer EJBs, it would need less resources to do the same job, reducing start-up time, memory usage and response time.

Final Thoughts

These arguments don’t consider any of the soft issues that surround the construction of a large J2EE system. There are often good non-technical reasons for choosing to use EJBs, and even to use many EJBs. Also, I’m not arguing that existing systems built with “too many EJBs” don’t work or should be rewritten.

What I am advocating is this: if you are building a large J2EE system, think carefully before scattering EJBs willy-nilly through the design.

¹ I can’t resist replying to two. First, my original post never advocated one EJB for an entire system. Hani might have understood this, but his writing was unclear enough that at least one of his readers didn’t.

And “l33t php app”? Is that the kind of reasoned, intelligent argument Hani is looking for?

² Even though accessing system resources in this manner is against the EJB rules.

³ See section 11.1.2 of the EJB 1.1 spec. It is possible to suspend one transaction and start a second one, but this is not typically needed in a commercial application.

⁴ Ten or twelve in debug mode, longer if the shared database is heavily loaded.

After weeks speculating about my secret birthday present, I found out on Saturday. My wife gave me an aerobatic ride in a biplane. Woohoo!

Here are me and my boys standing in front of the plane. The plane is a Pitts Special, designed specifically for aerobatics. It is really quite small – 20 feet wide, 18 long and, fully loaded, weighs only half as much as my car, empty.

Getting into the plane was pretty easy. The big trick is not to step where you shouldn’t, because the wing is made out of fabric, and a hole in it wouldn’t look good.

Once in, I was given a lambswool “helmet” to put on, complete with headphones (which double as earmuffs against the noise and cold) and microphone. Also wore my sun-glasses, which turned out to be a good move, because it was a little windy up there. There was a five point harness and secondary lap belt. The pilot helped me do up both, tightly.

While taxying, I got to listen in to the radio. It is really hard to understand what is being said—the radio receives a lot of hiss and the are voices are all crackly. Apparently you get used to it if you do it all day, every day. Because there is no tower at this aerodrome, pilots using the runway rely on everybody making the right calls at the right time and, of course, watching for other planes.

Another one of the flight company’s planes was also leaving then, so the pilots took the opportunity to do a formation take-off. The other plane was about a length ahead and to the right of us—maybe 20 feet away. The two planes accelerated from a standing start to the 150 km/hr or so take off speed while maintaining the 20 foot separation. Then they took off together, climbed and turned, all with only 20 feet between us. Very, very impressive!

Here’s us going over:

We then puttered around a bit, sight-seeing, but climbing, climbing, climbing. Finally, we were high enough and far enough away from everything to do some neato stuff.

The pilot, Phil Unicomb, was careful to communicate what each manoeuvre was before we did it, and then talked me through it as we did it. This made it so much more enjoyable. At the end of each one he asked “Was that OK?”, ready to pull things back a notch if I was having a problem. My reply was always “I’m good” or “I’m fine”, and I really, truly was.

Phil started us off with some steep turns. These are done with the wings at 60-degrees to the horizontal. To maintain height at that angle, the plane has to pull 2Gs, so you feel heavy in the seat. Then he did three or four barrel rolls, one of them in a shallow dive. The rolls were so gently done so that I didn’t notice any g-force, it was just that the sky and land turned through 360 degrees while I watched. Lovely!

At about this point, my legs started wobbling. I was a little anxious, but I didn’t think it was that bad! In retrospect, I was probably just cold, being several thousand feet in the air, moving at two hundred km/hr on a cloudy winter’s day.

We did some wingovers too, and a hammerhead turn. A wingover is where the pilot lets the inside wing stall in the turn, and the plane turns 180 degrees in no time at all. Fun! For the hammerhead, Phil took us into a straight up climb (90 degrees) until the plane was going quite slowly then turned us to the left so we were going straight down, then flattened out.

We did a full loop (inside loop where you climb first), and later on a half loop up followed by a half roll so we ended up 800 feet higher and going just a bit slower. That was a rush.

My favourite was the tail slide. Phil put us straight up, cut engine back to idle—it got eerily quiet, and I could see the prop turning—and then let the plane fall backwards for a second or two before kicking it forwards. The little Pitts fell for a bit more while the speed built up and then, with great thump, started to fly again. I can’t describe just how much fun it was to do that. I can’t even tell you why it was fun. It just was.

We also did some aileron rolls with stops at each 90 degrees, to show how precise the pilot and plane could be. Phil also showed me just how fast the plane could roll—360 degrees per second once the roll is established. This makes for rolls that finish before you’ve worked out what’s happening.

Toward the end Phil flew us upside down for a few seconds. Ha! Phil also flew us on the edge of the wing, 90 degrees to the ground. It takes a powerful plane to be able to do that.

Landing was interesting. It is not possible to see over the nose of the Pitts once it is landed. The pilot has to judge where they are by watching the side of the runway.

And that was all. Sigh. I could’ve stayed up for another hour.

Next time—and I’m pretty sure that there will be one—I’m going to:

• Do a flight on a week-day so I can spend half-an-hour talking to Phil before we go up (his Saturdays seem pretty busy)
• Ask for some negative-g and more falling manoeuvres.
• Wear something warmer than jeans.

If you’re interested in doing this yourself, I can heartily recommend Action Aerobatics up in the Hunter. It wouldn’t have been the same without Phil’s professional approach and unpretentious application of skill.

What a great Birthday Present! Thanks Karen!

Update: There is now a Yahoo Group for discussion of Crime Scene Cleanup: http://groups.yahoo.com/group/crime_scene_cleanup/.

The Crime Scene Cleanup Directory describes itself as:

… a listing of local and national companies that specialize in the cleaning of business sites, homes, apartments, and vehicles that have been contaminated by trauma, crime, or natural and/or accidental death.

Trauma Clean is an example of an Australian business in this directory. Trauma Clean’s site notes that:

Trauma Clean is not a conventional domestic or commercial cleaning service.

And here’s an article describing the business. Fascinating reading, but not over lunch.

via BlogSpot’s Google ads on Renaldy’s blog.

J2EE applications use too many EJBs. The correct¹ number of EJBs is one per component. My reasoning is below, but first a quick review of the technical pros and cons of using EJBs.

Pros:

• If you follow all the rules, individual EJB-wrapped components can be distributed.²
• Container provided resource pooling can be useful.
• Container manages transaction scope for you.

Cons:

• Any EJB takes a LOT more effort to implement than a standard Java object.
• Any EJB takes a LOT more effort to use than a standard Java object. PortableRemoteObject anyone?
• Any call to an EJB takes a LOT longer than a call to a standard Java object.
• Getting hold of container provided resources requires JNDI.
• CMP Entity EJBs are more effort to use even a roll-your-own persistence layer, let alone a purpose-built Object-Relational mapper.
• BMP Entity EJBs ditto.
• Stateful session beans are useless for any real world problem.³
• Configuring an EJB container ranges from inconvenient through to painful.
• Most commercial EJB containers are heavy-weight monsters that eat memory and CPU cycles for no discernable benefit.

Each of the advantages gained from EJBs, is gained, in full, with the first EJB you use. Additional EJBs don’t give additional advantage.

On the other hand, (most of) the disadvantages of using EJBs accrue with each and every EJB. Each additional EJB gives a bigger helping of disadvantages.

From here it’s a very small step to the conclusion that you should use as few EJBs as possible, preferably zero. However, if you find the advantages of using an EJB container compelling, then I recommend a maximum of one stateless session bean as the interface to each component.

¹ If you know of an application that would benefit from more EJBs than this, please let me know. I’ve yet to encounter one.

² Though I’ve never seen an EJB application gain any performance or reliabilty by distributing itself over multiple machines. IMHO, most applications don’t follow the rules strictly enough to allow transparent distribution.

³ Except that they are the only mechanism available to get hold of the SessionSynchronization interface, and thus the only way for EJB 1.1 objects in a container to “listen” for whether a transaction is successful or is rolled back.

Updated: This new entry extends and clarifies my argument.

Charles makes a delightful observation about emotion-filled technical debates. Great post! Go read it.

In Charles’ writing, I hear echoes¹ of this ancient bible philosopher:

“Meaningless! Meaningless!” says the Teacher.
“Utterly meaningless! Everything is meaningless.”

What does man gain from all his labor
at which he toils under the sun?
Generations come and generations go,
but the earth remains forever.
The sun rises and the sun sets,
and hurries back to where it rises.
The wind blows to the south
and turns to the north;
round and round it goes,
ever returning on its course.
All streams flow into the sea,
yet the sea is never full.
To the place the streams come from,
there they return again.
All things are wearisome,
more than one can say.
The eye never has enough of seeing,
nor the ear its fill of hearing.
What has been will be again,
what has been done will be done again;
there is nothing new under the sun.
Is there anything of which one can say,
“Look! This is something new”?
It was here already, long ago;
it was here before our time.

Ecclesiastes 1:3–10

‘nuff said.

¹ I was going to write “nEchoes”, but common sense prevailed.

Some time ago, Carlos Perez blogged on the Thinking Styles appropriate for different programming languages. His labelling of “Idealist” for the Java programming language is spot on.

In an ideal world, Java is the best possible language for solving any given problem. Java programmers like to live in an ideal world, so they pretend that Java is the best possible language to solve any problem.

I’m in two minds about this.

With my architect’s hat on, I can say that Java is not a bad answer to almost any commercial programming question. There is a market surplus of Java programmers, loads of (open-source and vendor-supplied) tools, stores full of good books and senior management doesn’t question the technology. In this light, the idealism around Java is a plus.

With my programmers hat on, however, the best I can say is that Java is a better answer than C++ to almost any commercial programming question. Java’s biggest flaw is that it takes such a long time to implement even the simplest functionality. Java Idealism rules out the possiblity of using any other technology.