JMS API Lacks Depth.

The JMS API still does not cater for a simple method to obtain the number of messages on a queue. Currently you have to jump through the following hoops to get the queue depth:
1) Create Connection
2) Create Session
3) Create QueueBrowser
4) getEnumeration
5) iterate through the enumeration while incrementing a count.

On some JMS implementations for large queue depths this approach has rapidly resulted in OutOfMemoryException, as the entire enumeration is loaded into memory.
So inevitably, the developer ends up dropping into proprietary code thereby losing portability and increasing vendor lock-in. OK this could be tempered by creating a factory pattern implementation ... but why, multiple times across many development organisations.

Many JMS implementations have a native way of simply obtaining the queue depth along the lines of the following:
1) Create Connection
2) Create Session
3) getQueueDepth(Queue queue)

This doesn't involve loading all the messages into memory, and it is s common that it ought to be added to the standard JMS implementation.
I believe that this should return -1 if it is not supported else return the actual queue depth.
There could be another variation,
int javax.jms.Session.getQueueDepth(Queue queue, String messageSelector)

I'm not sure whether this should be applicable to topics, as depth is relative to the consumer, perhaps the subscriber name could be passed in to a similar method.

Its coming up to 7 years since the release of JMS-1.1, surely this feature alone is worth releasing JMS-1.2.

Geek Reservists

Well done to the South African government for adopting a policy of open source. It is good to read that SITA has set up FOSS Program Office.
However I must note that their site does not play too nicely in my FF3.

Seeing that FOSS is all about the community, why don't governments encourage participation by civilians? Why not set up a Geek Reserve similar to the Police Reservist volunteers - they may even entice foreign volunteers that are interested in the platform.

Reward contributions with a medal/certificate or a tax break or a donation payable to the open source project platform that is being used and volunteer numbers will swell.

A good starting point for prioritising the migration would be a catalogue of software currently in use along with # of instances and licence fees that are currently funded by tax payers. Although volunteers are more likely to contribute in areas of their own interest, which may not necessarily coincide with governments priorities.

But before diving headfirst after the first replacement that is tagged as FOSS, a well documented and accessible architecture should be established like the US National Institutes of Health.