magpiebrain

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…

The “London Java”:http://javanicus.com/londonjava/ website is down at the moment, so my way of a reminder we will be having this months meetup at “Smiths of Smithfield”:http://www.smithsofsmithfield.co.uk/groundA.htm on Tuesday 13th.

[Updated 11/01/2004 18:18pm]: Jez has informed me that his provider has gone a bit screwy, so until it gets sorted the offical london-java site can be seen “here”:http://web1.2020media.com/j/jez/javanicuscom/londonjava/.

[Update 12/01/2004 14:42pm]: There is a “new domain”:http://www.londonjava.org/ for the meeting site. The updates blog link still seems to be broken, so use “the mirror”:http://web1.2020media.com/j/jez/javanicuscom/londonjava/ for now.

There has been much talk concerning frameworks recently. It seems that almost every opensource project that isn’t an application (and lets be honest, there are very few opensource Java applications) calls itself a framework. This set me to thinking – what happened to calling something an API? When does an API become a framework?

An API is a set of classes and methods (at least in Java parlance), packaged together. They typically provide features for a well defined scope. The Java Standard Edition includes many API’s such as the Collection API or the NIO API. Both are well defined in scope, packaged together and work consistently within themselves. By those terms, frameworks are also APIs. Something like Struts, which we can all agree on is a framework, certainly meets those criteria. So what extra features make Struts a framework?

Probably the key for me is the fact that a framework provides an extendable structure. With Struts for example you extend from the struts-provided base classes and create your own forms and actions. Of late there has been an increasing trend towards so-called ‘light’ frameworks, whose use is almost invisible from the application code’s point of view. Spring and PicoContainer for example use IoC to integrate your own components together, with themselves acting almost invisibly, but they’re still there.

By this reasoning, “Hibernate”:http://www.hibernate.org/ is not a framework (which I don’t think it is), nor is the recently announced “Morena”:http://www.gnome.sk/Twain/jtp.html product (although it bills itself as an “Image Acquisition Framework”). An implementation of the EJB specification arguably is a framework, as is the Servlet API.

Maybe I’m arguing with myself here, but I’m increasingly getting the impression that people are calling things frameworks as it sounds somehow bigger, more expansive, than just calling it an API. Semantics are important!

I’ve been writing some caching code recently at work and it occurred to me that I should really look into some caching API’s. Whilst talking to Matt at the last London-Java meetup, the discussion of caching came up. He said he’d looked at “OSCache”:http://www.opensymphony.com/oscache/, but decided against using it due to a complaint with its API. Apparently when you get an entry from the cache, if it doesn’t exist it throws an exception. Not fulling believing this to be true, I looked through the API docs (note to the OpenSymphony guys – a simple tutorial would be nice) to find that he is completely correct. This from the cache.getFromCache javadoc:

Throws:
NeedsRefreshException – Thrown when the object either doesn’t exist, or exists but is stale. When this exception occurs, the CacheEntry corresponding to the supplied key will be locked and other threads requesting this entry will potentially be blocked until the caller repopulates the cache. If the caller choses not to repopulate the cache, they must instead call cancelUpdate(String).

This strikes me has bizare to say the least. First off exceptions are being used to control logic flow, which is a bad thing. Exceptions are for errors in your code – be they user driven, programatic or due to system disruption (please don’t quote the whole NumberFormatException being thrown from the various number parse methods – thats just wrong). Secondly, the obvious (to me) way to design a cache is to allow a pluggable load strategy to the cache, and if the content doesn’t exist the cache itself goes and gets the content. Then if there is a problem loading the content you would get an error thrown, which would of course be an unchecked exception as it will be a programmatic or system environment error. Here the cache is saying “I’m stupid, fix me” and will then perhaps even lock your thread until you do. To be of any use to me I’m going to have to wrap OSCache with my own Cache class to do this for me.

I am struggling to think of a single advantage to this approach. Everywhere you want to use the getFromCache() method you are now forced to wrap it with a try-catch block, and then have to repopulate the cache if it fails. A pluggable content-loading system wouldn’t be hard to write. I have come to the conclusion that I must be missing something. Either the javadoc is wrong or there is a very good reason for getFromCache() to work like this. Can someone put me right?

“JXPath”:http://jakarta.apache.org/commons/jxpath/ is a Java API to allow “XPath”:http://www.w3.org/TR/xpath queries on Java object hierarchies. My first reaction was “fantastic!”. I’m a “fan(magpiebrain – What XPath is, and why its a Good Thing)”:http://www.magpiebrain.com/archives/000106.html of the simplicity of XPath but have had little need to use it (as in my day-to-day work I don’t use much XML), and initially I thought that JXPath would enable me to use XPath in other areas. After thinking about it for a while I came to realise that the only places in which I actually use a query language is when querying my persistence engines, which all being relational use SQL or something similar (for example EJB-QL or Hibernate-QL). To use JXPath I’d have to load the entire data structure to be queried into an object graph prior to being queried, as very few databases support XPath natively.

You could of course use your XPath queries within your code as Michael Nascimento Santos “points out(JXPath to rescue!)”:http://weblogs.java.net/pub/wlg/864, however I think the notion of replacing java code with Strings just to reduce the size of your code is probably not a great idea. I for one would rather have verbose Java code (which would in all likelihood run faster) than use an XPath query either embedded as a string in the code itself or maintained in a separate location. If the query is likely to change at runtime its a different matter of course.

All of this did start me thinking about something else though. I have been looking at Java-based rule engines of late, most notably Drools. Drools has you define your rules within a configuration file, for example I might code a condition that states if a customer’s wage is more than a certain amount, I make them a special customer (note I’m simplifying the code a little):

user.getWage() > 25000
...

user.setSpecial(true);

Here the condition certainly lends itself to the use of XPath, or at least the use of embedded XPath query using JXPath might be of benefit. I might talk to the Drools guys about this unless I realise its a stupid idea or I get distracted by something else…

As Andrej Koelewijn rightly “points out(Andrej Koelewijn – Persistence layer poll on OTN)”:http://andrej.racchvs.com/archive/2003/12/18/persistence_layer_poll_on_otn.html, the Oracle Technology Network’s “JDevelper site”:http://otn.oracle.com/products/jdev/index.html has survey on which persistence layers people are using seems a little sparse – “Hibernate”:http://www.hibernate.org/ (amongst others) is not included. This may be either because Oracle are worried that their own products might loose the poll, or it could be that they haven’t heard of Hibernate. Both “BC4J”:OracleAS TopLink, the #1 Java object-to-relational persistence architecture, and “TopLink”:http://otn.oracle.com/products/ias/toplink/index.html are included, both of which are Oracle products. In fact the TopLink product page contains the following quote:

OracleAS TopLink, the #1 Java object-to-relational persistence architecture…

One wonders if this quote is based on a survey where TopLink was the only possible answer…

One of the reasons for my annoyance on this poll is that I have a real desire to find out just what persistance frameworks people are using – vendor specific surveys clearly aren’t the way to go.