magpiebrain

I’ve been semi-lurking of late on the PicoContainer’s developer mailing list, where much of the discussion has been over to the topic of the refactoring of the existing PicoContainer, PicoExtras and NanoContainer products. Given the nature of the list, the focus of the refactoring work has primarily been in order to make development and reuse of the products within other projects easier – quite often the topic of build dependencies gets mentioned. Given that I want to use PicoContainer/NanoContainer at work, it got me to thinking as to what I would need the projects to have in order for me to be able to use them. More generally, what do I need from any Opensource project in order for me to justify its use in a development project, be it Opensource or Commercial? On a post to the list, I summed this up as being able to say to my colleagues (be they fellow developers or management): “That’s what it is, here’s what it does, here’s how to use it and that’s why we are using it”.

That’s what it is

An Opensource project needs an identity. That is to say it needs a name, and something along the lines of (I’m going to hate myself for saying it) a mission statement:

Project Zebra aims to provide an Opensource, cutting edge monochrome solution to the ongoing shortage of food for lions.

It should also be available in a nice, downloadable package (or one or two at most). I want to be able to say “I just downloaded it, we have the Jars”, not “I started up SmartCVS and grabbed the most recent version”.

Here’s what it does

This should be more specific than a mission statement. I want a feature list, and perhaps even a nice comparison matrix if there are similar products available. If I can’t work this out from looking at your website for less than five minutes then why do you have one?

Project Zebra can:
* Merge into black and white foliage
* Look like a horse and yet not be able to be riden
* Provide either black zebras with white stripes, or white zebras with black stripes

Here’s how to use it

Probably the most important thing – good documentation and example programs. I may well be able to work out how to use project Zebra by looking at the code, but what about the developer sitting next to me who might have to fix my code when I’m on holiday? Having no documentation or examples might be fine for in-house development, but please be nice to your potential users.

That’s why we are using it

You need to be able to justify your use of project Zebra, and this can only be done if the previous questions can be answered. If your Opensource project cannot answer the above questions when asked of it, perhaps it should, or perhaps you should reconsider who exactly your target audience is.

I found myself writing a response to Jared Odulio’s “post(EJB should really, really, really, really, really, really go away!!!)”:http://blogs.application-servers.com/roller/page/jaredflo/20040122#ejb_should_really_really_really, 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.

Jeffrey Aaron Farr has managed to “accurately sum up(IoC > Dependency Management)”:http://www.jadetower.org/muses/archives/000020.html 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)”:http://www.martinfowler.com/articles/injection.html 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”:http://java.sun.com/products/JavaManagement/ specification (which can be considered a Type1/2 IoC hybrid container) makes great use of it.

I recently “took offence(Joe Walnes’ Blog – Inversion of Control and Dependency Injector Pattern)”:http://joe.truemesh.com/blog//000162.html 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)”:http://martinfowler.com/articles/injection.html. 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”:http://www.amazon.co.uk/exec/obidos/ASIN/0321127420/qid=1074517170/sr=1-2/ref=sr_1_11_2/026-5708252-6942053. The ludicrously well known “Data Access Object(Core J2EE Patterns – Data Access Object)”:http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html 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”:http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html 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.

This little beauty was spotted in my struts code by a colleague of mine, clearly the result of too little coffee in the morning:

ActionErrors errors = errors = new ActionErrors();

Whilst I say this is a mistake, it actually complies and works. Here I’m assigning an object reference twice. It also works with multiple references:

Long p;
Long l = p = new Long(10);

Which results in both p and l are referencing the same object. It has to be said that I can’t think of a single legitimate reason why you’d want to do this – I blame the lack of coffee this afternoon for me spending even this much time on it…