magpiebrain

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…