magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Posts from the ‘Development’ category

“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.

ONJava.com’s Top 15 Ant Best Practices is a good read. Speaking as someone whose new build files tend to be copied and hacked about from existing projects, I really should pay more attention to my poor neglected ant files. I especially liked the recommendation to use zipfileset to create archives, as it means you don’t have to create temporary directory structures prior to creating your JAR, WAR and EAR files – something I do quite a bit.

I found an interesting bug in my code today. I’m storing an object in a cache, and using a couple of indexes to address it. One index is a normal HashMap object, which is indexing the object based on its unique ID. The other index is applying a grouping – several objects with the same grouping could exists so here I use a HashMap indexing a HashSet object. When I need to update the object, I call put on the ID index, which updates the entry. For the grouping index, I get the HashSet and call add. I noticed that the unique ID index was updating, but the grouping index wasn’t – I had of course failed to read the documentation for HashSet‘s add method:

Adds the specified element to this set if it is not already present.

This contrasts with the HashMap‘s put method:

Associates the specified value with the specified key in this map. If the map previously contained a mapping for this key, the old value is replaced.

Now I should of read the documentation, but the reason for my mistake is that I knew that a HashSet was actually backed by a HashMap – as such I assumed add would just call put on the underlying HashMap using the same object as a key and the value. Of course I am misusing a Set here – a Set is a collection of objects with no duplicates. When calling add equals is called, shows that the object is already there, and therefore doesn’t re-add it. Really I want the behaviour of a Map with the simpler interface of a Set, so I should just stop complaining and write my own wrapper class, shouldn’t I?

Well, much fun was had by all, especially the very drunk guy who started eating rice with his fingers whilst swaying slightly. I managed to meet up with “Simon Brunning(Small Values of Cool)”:http://www.brunningonline.net/simon/blog/, “Simon Brown”:http://today.java.net/pub/au/82, “Jeremy”:http://javanicus.com/blog2/ (to whom much kudos must be given for organising the whole thing), “James Strachan”:http://radio.weblogs.com/0112098/ who was kind enough to field a vast array of questions on all things Groovy, Drools (mostly me) and Core Developers and many, many others. James also dropped some hints that I should look at “PicoContainer”:http://www.picocontainer.org/ – expect a brief comparison wrt the “Spring Framework”:http://www.springframework.org/ in the next few days…

I’m off to the London Java Xmas Meetup after work, and don’t know what anyone looks like. I have this horrific notion that I’m going to introduce myself to a complete stranger who has no idea what I’m talking about, and rather than listening to my inane prattlings he’ll beat me to death with his Shoe. Either that or I get lost.

A nice little site this – “Widgetopia”:http://www.eleganthack.com/widgetopia/ catalogues various widgets from websites. Resources such as this can help show just how functional a website’s UI can be, and more importantly can give some well needed inspiration to webapp UI designers. Its time webapp developers realised that their interfaces don’t need to be ugly, bland affairs, and that beyond looking nice, a decent functional design can make for a more pleasant and efficient user experience.

My ongoing campaign to understand all facets of the “Spring Framework”:http://www.springframework.org/ has been hampered somewhat by the fact that I haven’t been able to develop anything with it. Using it at work is a non-starter, so I’m looking at developing a project at home which is big enough to explore the various aspects I want to explore, but not so big that it becomes too much work. And ideally it needs to be useful. I certainly want to use AOP with the Spring Framework. Documentation for Spring’s AOP support is sparse to say the least, but I did manage to find a brief overview from the old Wiki which gives me enough of an idea. The problem with these simple demos however is that they have to be simple enough to cover in a straightforward manner but always end up being a trivial example, that doesn’t really help show the power of AOP. Perhaps I’ve found the topic for another article…
I am seriously considering writing an aggregator webapplication actually. Given my knowledge of Informa, RSS and blogging as a whole it would make sense. The only problem with that idea is that I don’t need one really, and I’m not sure anyone else does – blo.gs works fine for me. Oh well, lets see what the new year brings.

Of late, I’ve been looking into a variety of technologies, with a view to reimplementing an existing web application. “Spring”:http://www.springframework.org and “Hibernate”:http://www.hibernate.org/ are a given. Even if it offered no performance improvements over CMP Entity Beans, Hibernate is much nicer to work with. Once you get your head around Spring, its benefits become clear – cleaner, simpler code with less configuration hassles can only be considered a good thing. Next up I’ve been looking at business rule engines and user interface scripting.

Currently, both “Jess”:http://herzberg.ca.sandia.gov/jess/ and “Drools”:http://drools.org/ are striving for my attention, with Drools wining out so far purely because of its better documentation. Both should theoretically allow me to remove business rules altogether from my Java code, assuming I can work out a design whereby everything hangs together properly. For the UI, I had almost come to the conclusion that I would be hand-scripting it, but I took a look at the “Thinlets”:http://www.thinlet.com/ project, and was impressed by what I saw.

From the website:

Thinlet is a GUI toolkit, a single Java class, parses the hierarchy and properties of the GUI, handles user interaction, and calls business logic. Separates the graphic presentation (described in an XML file) and the application methods (written as Java code).

Its compressed size is 38KB, and it is LGPL licensed.

Thinlet runs with Java 1.1 (browsers’ default JVM) to 1.4, Personal Java, and Personal (Basis) Profile. Swing isn’t required.

The online demos look impressive. My only concern at present is the requirement for a Java plugin. Assuming this isn’t an issue for my target audience (and it depends greatly on which of the projects I take on – there are a couple on the table) I may well consider using it. It certainly helps support the argument that a thin (web) client can also be a rich one.

I’ve stayed out of much of the recent debate concerning Exception handling, mostly because I realised I didn’t have much of an opinion on the subject and suspected that even if I did the code I wrote probably didn’t match what I thought I should be doing. To be honest I kind of handle exceptions without any real thought, and after reading Gunjan Doshi’s article “Best Practise For Exception Handling(ONJava.com: Best Practices for Exception Handling [Nov. 19, 2003])”:http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html realised that at least as far as he was concerned, I certainly have room for improvement. Looking over my code after reading the article I’ve noticed that I have been correctly catching user-caused exceptions and erroring appropriately – given that 90% of these errors are caught in validation code its not that surprising. With exceptions generated due to programming errors or problems with resources I’ve noticed a couple of areas where the user has not been properly informed that something has gone decidedly wrong – a few of the exceptions are simply being consumed, logged, and ignored.

Concerning the Checked exceptions vs. Unchecked exceptions debate I’ve always been a big fan of checked exceptions. This probably stemmed from my C programming days when many a programming error was caused by forgetting to check the return type of a system call for an error code. Checked exceptions ensure that at compile time the programmer has taken some action to deal with the result. Gunjan is of the opinion that the only point in throwing a checked exception is when the client can actually do something about it, which is an approach I can certainly understand. Again carrying out a brief audit of my code I have found that all too often I am throwing checked exceptions purely to make sure I catch and handle them in my code rather than giving any real thought to if they should be unchecked. All in all, the article is a good read, and whilst it may not end the debate on the subject of proper exception handling it may at least raise some interesting approaches.