Archive for December, 2008

Groovy properties

I’m on a Groovy buzz at the moment. I figured that I’d learn the language properly rather than poking around, doing stuff in Grails. It’s one of Groovy’s huge advantages that you can hack away as a Java programmer and be fairly productive. So playing with properties:

class Thingo {
    def value
    def anotherValue

    void setValue(Integer value) {
        this.value = value * 2

thingo = new Thingo(value: 3);
println thingo.value

thingo.value = 2
println thingo.value

thingo.anotherValue = 2
println thingo.anotherValue

The results:


A few things are going on here:

  • When we construct our Thingo in the script above, Groovy calls the default constructor, and immediately updates value. As a setter method has been defined “setValue()”, Groovy does not generate a default one and uses what’s there -the one we’re using to encapsulate some programmer-defined variable fiddling.
  • Likewise, when we assign a variable to value, Groovy makes use of our setter to update value.
  • When we assign a number to anotherValue,  a default setter is created at runtime and is used to perform the update.

I’m really enjoying the benefit of the groovyConsole – it lets you mess around with code really easily, without needing to even save it. Low-ceremony programming at it’s best.

If you’re looking at learning Groovy properly, I strongly recommed Programming Groovy by Venkat Subramaniam. Just like the language itself, it gets you doing stuff very quickly.

Would you like a toolbar with that platform upgrade?

It’s innocuous enough. “A new update of Java is available. Do you want to upgrade now?”

Sure, OK. Why not. Click. Dowload. Install.

Java installs Yahoo toolbar

WTF? What’s the story here? Are Sun that strapped for cash that they need to make a few bucks by installing Yahoo’s “value adds”?

A fire-side chat about programming

Every once in a while I go through a period of introspection where I pose questions like “why am I solving the same stuff all the time?”, “is there a better way to be doing this?” and “what’s around the corner?”. I think it’s pretty healthy, and I prefer to give it a good two weeks of thought straight rather than to constantly be going through that process (which I find pretty distracting at the 10k foot level). As part of that I have been reading an awesome book in the last week called “Secrets of the Rock Star Programmers“. It’s a collection of interviews with some of the biggest/loudest names in programming, and contains the sorts of conversations that you would have down at the pub with these guys. I think that it’s quite an introspective, passing-on-wisdom type of book in the vein of “The Pragmatic Programmer” (TPP), but for the Java/.Net generation. Unlike TPP, it covers subjects around the meta-level stuff like keeping up to date versus trend chasing, and work-life balance amongst the day-to-day grind of pending deadlines. The really interesting thing is the common threads coming out despite the personalities and differences in approach. The book’s style is very different to TPP’s in that it is not prescriptive, but rather lets you draw your own conclusions. It has been an interesting read that I think I will keep coming back to, and one that I think I would not have gotten as much out of at the beginning of my career. I strongly recommend it, especially if you happen to be going through a “so, what’s it all about, then?” stage and don’t happen to have your favourite rock star around to chat to.

Why wrong licenses kill good products

Being on the ODBMS train of thought, I checked out a few products that are out there, and something struck me – all of them would be really difficult to bring in to a project. The reason is not technical, but rather one of hassle. All of the products are either proprietary closed-source or GPL dual-licensed. These licensing models actively discourage people from bringing them into the enterprise.

Commercial software is notoriously hard to get approved, and there is generally a long-winded process that has to be followed so that the bean-counters can say “can’t you use an open-source alternative”. GPL dual-licensed stuff is almost as bad! Most of the places I have worked have a blanket ban on GPL software (excluding GNU-type tools which generally sneak under the radar in a server installation). Financial companies in particular are almost paranoid about this. Anything that’s not Apache, or LGPL has to go to the legal department, who will take ages only to eventually say “we’re not comfortable with this”.

Licensing is one of the main reasons I conciously jumped ship from the Microsoft world to Java. I found it really painful to get the most basic library approved for use. Who cares that tool X it would save me a week of development – it cost $50! Then I jumped into Java and it was like a blessing. You need a rules engine? Workflow? Plugins for XML for your IDE? No approval process – no worries! My life became much, much easier. I could just dowload what I required and get on with doing what I needed to do.

There are always exceptions. MySQL springs to mind. The fact that it is standalone made people a bit more comfortable using it without the specter of viral licensing rearing its ugly head. ODBMSes are not like a normal database. They integrate directly into your code and distribution to your server means that they are a core part of your application. I suspect that GPL may be triggered at this point because of the “distribution clause”. I have read the exact opposite on the DB4O forums, which say that server stuff is OK to use under GPL, but distibuting client (desktop) software that uses the ODBMS forces GPL on your application.

Hmm. This is a pretty murky line, and one that I’m not comfortable with. What about if you “distribute” your server software around a cluster? I’ll be happy to put my hands up and just throw this in the “too hard” basket. If I can’t advocate that a piece of software has no legal repercussions on the ultra-proprietary system that I’m writing, I will lose no sleep whatsoever looking somewhere else. I suspect that I’m not the only one. It seems that there is a fine line between external dependency and a core library that is part of the application.

I appreciate why dual-licensing is there, and acknowedge that it’s a valid business model – for certain types of applications. However, you just can’t see it working everywhere. How far would Spring have gone if it was GPL dual-licensed? You only have to look at ExtJS to see how well-received frameworks or libraries are when it becomes too hard to justify their use.

Most large organizations in my experience are more than happy to buy support for LGPL stuff. Once it’s in there, someone wants the reassurance that there will be someone there to bug in case of difficult issues or simply to point the finger at (depending on the company culture). Dual-licensed stuff won’t even get it’s foot in the door – not even a sniff at success. I would really like to use an OO DB in a real-world setting, but it just seems like it would be far easier to get around the hassle of getting it approved if I just used something that’s not quite a 100% fit for the use case. That’s a real shame, and the software engineer in me just sighs deflatedly as the realist wins again in the face of pending deadlines.

Maybe that’s why so many people put up with the object-relational mismatch instead of trying a different approach. In the world I live in, an administrator’s “no” outweighs a technical “yes” every time.

This post is not intended to create FUD, just to outline why uncertainty may be enough to stop someone working with what may otherwise be brilliant stuff.

When a Cache is more than a Cache

Recently I have come across a number of instances when I have needed to perform searches across data cached in memory. Standard cache implementations, however do not provide anything more than basic key-value lookups, which is a bit of a pain. One of my colleagues came up with a clever solution to this – keeping a seperate data structure in memory that acts as an index specific to the search at hand. Ehcache provides callback hooks that can be triggered when an object is about to be evicted. This way you can delete the object from the index when the eviction policy says that it’s time to go.

It’s a neat idea to get around the immediate requirement, but I am not convinced that it is the way to be doing things. The need to create supporting data structures and manage them on a per-search basis smells in a big way. Ideally what you want is a proper, searchable, in-memory database, like JavaDB/Derby/Cloudscape but without the hassle of needing to do O-R mapping on arbitrary pojos (updated: Berkely DB comes pretty close). So this has got me thinking that perhaps OO databases are the way forward here.

The last I heard of people I knew doing anything with them was nearly a decade ago, and the problems around their management were highlighted in my databases subject at university. Basically “don’t go there” was the general advice. I don’t know that the arguments around them apply any more. Integration databases (for people poking around in your data *ugh*)  aren’t as common these days thanks to a better awareness of integration options (Martin Fowler wrote about this recently). I suspect management tools have gotten better over a decade. If not, it won’t be long until scaffolding via Grails takes care of the mundane stuff for DB4O at least. Steve Zara writes about this on his blog. Steve also discusses using DB4O as a cache. It’s definitely worth taking a look at, especially as to how it might hook in with eviction policies. Perhaps used hand in hand with the callback hook technique above? DB4O might just be the peanut butter to Ehcache’s chocolate.