Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘January, 2004’

I found myself writing a response to Jared Odulio’s “post(EJB should really, really, really, really, really, really go away!!!)”:, and realised that this was about the third time I’d written such a response this week. I felt putting the response here may be of benefit, at least to promote some legitimate debate on the subject (of which there seems to be little at present).

Jared Wrote:

EJB really sucks, Wanna discuss? First its principle contradicts some fundamental Java development pattern (e.g. multithreading for one). Second it’s the SUV of distributed computing; inadequate for its purpose, overkill for how it is currently being used.

I am beginning to suspect that those who admonish this just want to make more money(if they are an EJB vendor, if they want to overprice a project, if they want to bring up the false sense of future-proofing) and stretch their resumes.

People should really realise that EJBs are very good in certain very specific circumstances, and is overkill for most. Saying EJB’s should ‘go away’ is missing the point completely. It is an important tool in a J2EE developers aresenal, but it isn’t the alpha and omega. The majority of the backlash against EJB’s has come from people who have either used them in the wrong place or just didn’t understand how to use them properly. Perhaps some people were mis-sold EJBs by their vendors or even by sun, but those rejecting EJBs out of hand may be in danger of throwing the baby out with the bath water.

This is rapidly becoming a log of my stupid mistakes, but I thought I’d post another beauty from the Extremely Tired And Lacking In Coffee school of programming. A stored procedure was returning some very strange results – namely it was returning the same record no matter what was passed in. My procedure looked like this:

	RETURN mercury.GenericCursor AS
res mercury.GenericCursor;
	SELECT someinfo
	FROM customer
	customerid = customerId and

Anyway, no matter the customerId passed in, back came the same record. Eventually my more SQL-minded colleague pointed out that Oracle is case insensitive at matching the parameter/column name and returned me the first record. A quick rename of the parameter to customer_id and all was well. It would of been nice if Oracle had thrown an error or at least a warning when I gave it the procedure – even so, not one of my finer moments.

Those of you amongst the (very) small band of commenters to my blog may of noticed that the comment form wasn’t the nicest around. Most of this was due to the complexities of committing myself to a purely CSS based layout, but it was also due at least in part to me being very lazy. Anyway another excellet article by “Simon Willison(Sitepoint – Simple Tricks for More Usable Forms by Simon Willison)”: has encouraged me to clean the comment forms up a bit. The CSS is simpler and the forms look a little better. Feel free to post any comments on the new layout.

I have also decided to put off the upgrade to “MovableType 2.661”: until Jay Allen has released his next update to “MT Blacklist(MT Blacklist – A Movable Type plugin to eradicate
comment and trackback spam)”: – I’d rather upgrade both at once. MT 2.661 includes some spam fighting features – as well as restricting the number of posts that can be made in a certain amount of time, it also uses a redirect link for in comment links, so defeating those spammers who are attempting to increase their Google page rank. Due to the way MT Blacklist works it actually circumvents the comment throttling, but Jay is busy “working on a fix”:

I have also been toying with the idea of a site redesign again, perhaps this time using colours other than black and white. Part of me thinks that this might be a step too far.

Jeffrey Aaron Farr has managed to “accurately sum up(IoC > Dependency Management)”: some of the points I’ve been wanting to make concerning the feedback (mine included) to the “recent article(Inversion of Control Containers and the Dependency Injection pattern)”: by Martin Fowler, and has done so far more eloquently that I would of. He correctly points out that IoC is about more than resolution of dependencies, a point Martin himself makes in the article:

The conclusion I’m coming to is that, as Fowler points out, there are lots of forms of inversion with Dependency Injection merely one of them. For example, in all three of the container frameworks mentioned above you will find at least three types of IoC:

  • Dependency IoC
  • Lifecycle IoC
  • Configuration IoC

It’s important to recognize these other aspects as part of the IoC design pattern. IoC is not just about dependency management.

I did initially take issue with Jeffrey classing Configuration IoC as being different to Dependency IoC, although realised he may have a point. Clearly a dependency is something which a component requires to do its job – this may include information traditionally thought of as configuration data, such as the location of a database. What about a path for logging? There may be a default directory that can be overridden – in which case is this path a dependency, or simple configuration? In this case the path is not required for the component to work.

Clearly dependency is required before the object is used (something which Type 3 IoC containers such as PicoContainer can enforce), however many configuration-type values may be legitimately changed after creation, something which Type 2 IoC containers such as Spring would be very good at, but which Type 3 IoC containers could not do without recreating the component with the new configuration data. The question remains as to how useful configuration IoC would really be, although the “JMX”: specification (which can be considered a Type1/2 IoC hybrid container) makes great use of it.

Thanks to my move from online aggregator to “Bloglines”: I’ve added a blogroll, giving a sample of my daily reading. Not everything is there, but I’ve cherry picked the most interesting stuff. Bloglines is a similar service to – in that it provides an online aggregation service. The difference is that it records which posts you have read (and keeps them synchronized from site to site) and that you actually read the posts within bloglines itself much as you would with a standard desktop aggregator.

I recently “took offence(Joe Walnes’ Blog – Inversion of Control and Dependency Injector Pattern)”: at the fact that Martin Fowler has decided that the well known phrase Inversion Of Control was no longer suitable, and instead decided to rename it “Dependency Injector(Inversion of Control Containers and the Dependency Injection pattern)”: Among my reasons for this annoying me (beyond the fact that even this new term isn’t completely correct) was the fact that in many ways renaming such a well known pattern can make discussion of the pattern a problem – one person talks about IoC, the other about Dependency Injector, another talks about the Dependency Inversion Principle and so on. Martin’s trait of doing this is evident in his otherwise excellent “Patterns of Enterprise Application Architecture”: The ludicrously well known “Data Access Object(Core J2EE Patterns – Data Access Object)”: is nowhere to be found – it was only via a google search that it became clear that “Gateway” was what I’m after.

The Gateway pattern as outlined is actually far more of an abstract pattern, and not a direct replacement for the DAO pattern. Gateway needs to be combined with the Data Transfer Object pattern (sorry, Value Object) to produce a true DAO pattern. Gateway as it stands is a pattern used to provide a simple interface to some complex code, which is otherwise external to your application code – it’s really one of those no brainier patterns, most of us for example wrap third-party API’s with our own code.

Redefining otherwise confusing terms as something easier to understand is all well and good, but there comes a time when renaming even a confusing term (and DAO for me does exactly what it says on the tin) becomes counter-productive due to the widespread knowledge of the way its defined now. The windows UI for example contains many inconsistencies that make learning it more awkward than other UI’s, however MS are not going to start changing it now – they have millions of users worldwide who know how it works right now. Perhaps people should start employing a more pragmatic view before they start renaming things all over the place.
I throughly recommend you read Martins book though, its certainly the best treatment of the subject of Enterprise patterns I’ve seen to date, author idiosynchrocies aside. I can also recommend Sun’s online “J2EE pattern catalogue”: which covers some of the same ground, albeit in less detail and as a free online resource.

By and large, I’ve been able to ignore the whole character encoding issue in Java. During a move to a new server however I had to sit up and take notice. Part of our code is using the getBytes() method to prepare some text files. We’d been using the default method, whose documentation states:

Encodes this String into a sequence of bytes using the platform’s default charset, storing the result into a new byte array.

The behavior of this method when this string cannot be encoded in the default charset is unspecified. The CharsetEncoder class should be used when more control over the encoding process is required.

Our new machine of course defaults to UTF-8 unlike our other servers, so upon producing our files it duly screwed up all our £ symbols. A system-property change later and all was well, but it has just reinforced the fact that I should really pay more attention to all those little caveats in the API documentation.