New found liking for dessert wines.

I have just had a bit of an education...

I've just spent a weekend on the Isle of Wight with my sister; Saturday afternoon was spent sharing a significant part of my whisky collection with some old friends. Chris (who happens to be a very talented musician) returned my collection of CDs that I accumulated on my '03 roadtrip and told me how much he had enjoyed 'Los Hombres Calientes'. I'd forgotten that those CDs were in that particular part of my collection, but was very please to know that they had given him so much pleasure.

After a couple of hours drinking whisky, we drifted across into discussing wines. I stated that I had never come across a dessert wine that I liked, with the honourable exception of the occasional Italian Vinsanto. I declared that they were all too sweet and sickly.

Rather well lubricated by this stage, Chris returned with a wax-sealed bottle and introduced me to 'Royal Tokay'. I had heard of 'Tokay' before, but today was the day when I discovered that it was a tiny wine producer in Hungary, costing £30 for an half bottle of the 'Royal Tokay'. I'm not a wine writer so I won't even try to describe what it tasted like; but after cleansing my palate with a little water, I enjoyed one of the finest flavours that it has been my pleasure to experience.

I am now on the look out for Tokay, and I want to try the 'Imperial'.

The Speed of Light?

THe night before last I must have been having some corking dreams, because I woke up this morning with a question that I would love an answer to.

'How does the quantum foam effect the speed of light?'.

For my readers who are not physicists, let me break this question down.

The 'quantum foam' is a descriptive term for the fact that there really is no such thing as a vacuum. Due to the probabilistic nature of quantum mechanics even in a space where all matter as we recognise it has been removed, particles continually pop in and out of existence. Energy is conserved because these particles disappear as rapidly as they appear.

This being the case, I wondered whether the speed of light is in some way determined by it's interaction with this quantum foam.

A side query is whether the increase in mass associated with objects moving relatively faster (most obvious as the speed of light is approached) is in some way connected with interactions with this foam. as masses move faster relatively speaking, they sweep out more and more space, vastly increasing their chance of interacting with these virtual particles.

Singleton - Pattern or Anti-Pattern?

It's interesting to see how various developers respond when you ask them about the singleton pattern. Most react positively, others say that it is an anti-pattern of the worst form.

Why it is considered an anti-pattern by some?

1. In Java it doesn't always meet the contract of the 'Singleton Pattern' as defined in the GoF book. Classloaders mean that more than one instance of a Singleton can exist in the same JVM.
2. Developers often use it as a dumping ground for de facto global variables, harking back to the most unstructured early days of programming.
3. Implementations often feature 'Singleton' in the names of implementing classes and other code becomes dependent on the fact that it is an instance of the singleton pattern.

I believe however that there is nothing wrong with the singleton pattern, just in implementations of it.

One should think of the singleton pattern as an implementation pattern for the factory and pool patterns. Developers should be handed a factory or pool and told only that it will give them an instance of a particular class or interface on request. They shouldn't know that it is the same object instance each time.

This allows the developer of the pool or factory to make efficient use of available resource, if possible, but also allows the implementation to be changed if necessity dictates. By hiding the usage of singleton behind the pool or factory patterns, code fragility is avoided.

J2EE misconceptions - Part 1 (of quite a few actually).

On every project I never fail to be surprised at how little supposedly experienced J2EE developers actually know. This week I found myself asking team members if they actually had read the EJB specification and the answer came back a resounding 'No!'.

It seems that all too often when people are learning J2EE and EJBs in particular, they go and look at the specifications with a beginner's eye and form the impression that the specification documents are dense and impenetrable. They never go back with a more experienced eye and have another go. When I went back and re-read the specifications half way through my first J2EE project I suddenly realised that they were really useful and were packed full of vital information that allowed me to treat J2EE more as a science than as the black art practiced by so many.

The misconception that I want to address with this post is around Container Managed Transactions (CMTs). Let me ask you a question and please be sure what you think your answer is before you move on.

In what circumstances do CMTs roll back?

Take a second or two.

The answer that I usually get is: 'When an exception is thrown.'

Trouble is, the answer is sort of wrong.

The correct answer is: 'When an unchecked exception is thrown out of the transaction context or when EjbContext.setRollbackOnly() is called.'

What many of the developers I talk to fail to realise is that checked exceptions do not roll the transaction back.

So did you get the right answer?

UML Abuse

Had a mixed day at work today, good and bad.

The bad today was around a discussion of how we were going to use UML to analyse use cases. All was going well until we got on to discussing how to model the user interface. We need to record the navigation between screens, the decision made was to do this with a mixture of class and statechart diagrams. I argued against this and suggested Visio, but was overridden on the basis that we wanted to do it all in UML via Rational Rose.

Thinking back I realise that I have actually seen this a lot, people determinedly using UML when another style of diagram would have been more appropriate. I seem to recall that Jacobson, Grady and Rumbaugh, when they first wrote up UML, were quite clear that while the diagrams covered the majority of design cases, they by no means covered them all. Where has this attitude gone?

Does anyone else see UML abuse as a problem?

Name Dropping

I had an interesting day yesterday, some guys from JBoss came over to sell a support package to the project that I am working on. So I found myself, just before lunch, shut in a meeting room hearing the pitch made by a commercial venture on the back of open source software.

I can certainly see that there is money to be made by their business model. In commercial and public sector there is the concept of 'due diligence' hereafter known as 'arse covering'. The support packages on offer provide exactly the right feeling of security for management and customers, in this case backed up by genuine knowledge of the product.

Certain of the more rabid open source fans I have met believe that this is a dilution of their long term goal. At present I have to disagree, because of this commercialisation the rate of development in JBoss is extremely high and that benefits anyone who needs an application server and can't afford the cost models imposed by companies like BEA. I don't know whether a successful business can be established long-term by paid for arse covering, but we will see.

After the meeting I adjourned to the cafeteria to share a coffee with the gentlemen from JBoss and had an interesting time talking to one of the more vocal EJB3 supporters that I have come across. He was very clear that the current 'issues' with JDO are all the fault of the JDO specification team and how they 'snuck out' the candidate specification over Christmas. I certainly agree that it was not a time best calculated to make the right impression. I have a suspicion that the actual cause of the release date was the feeling 'Right let's get it finished and have a good Christmas.'

I have to admire the detachment displayed in discussing how the current situation was in part due to the frictions between a specification driven by large business and a specification driven by a thriving user community. I found myself agreeing that there was room for both specifications. Having more than one persistence specification allows me to exercise one of my dictums: 'The right tool for the right job.'.

My radical proposal to resolve the current problem is to go ahead and put the mechanisms in place for migration from JDO and EJB3, but also state that mechanisms for the reverse migration should be part of the EJB3 specification.