My son asked me today: "You know that ballot Dad? So what happens now it's over?". He was referring to a proposal I've been involved in which has now been accepted and which I'll be working on for months to come. So I thought I'd try explaining it in simple terms so that he, and other members of my family who are a bit mystified about what I do, might understand a bit better.

The proposal is to make a change to Java. Java is a programming language plus some other stuff that lets programmers write computer programs that can run unchanged on lots of different types of computers.

I won't bore you with the technicalities of the proposal as that's written up in a so-called "Java Specification Request": JSR 291. Suffice to say it gives programmers a way of splitting large Java programs into smaller "dynamic components" which fit together in a particularly neat way. I said "dynamic" because these components can be switched in and out of a running system without having to stop the system and restart it, which is not as easy as it sounds if the system needs to continue running for a long period, like months or even years. Think of changing the wheels on a car while the car is still moving...

The proposal had to be voted on by a standards group which looks after Java, and earlier today the ballot ended and the JSR was approved.

So, to answer my son's question, I'll be leading a group of experts and will be producing three things. We will decide on the specification for the JSR: what the technology should do. We'll provide a reference implementation: an example of how the specification can be implemented, i.e. some programs. Finally, we'll provide a technology compatibility kit: some tests that someone uses to certify that their own implementation of the specification is, in a pretty specific sense, acceptable.

The really nice part is that we don't have to start from scratch. In fact, the first release of this JSR will be based closely on some existing technology produced by an industry consortium known as the OSGi Alliance. They have been working on this technology for several years -- I only got involved a couple of years ago. Another pleasing aspect is that several of the experts who will be working on JSR 291 have also been working in OSGi. Not only do they know their stuff, but we already know each other and have worked together successfully in the past.

But these things never turn out to be quite as simple as you expect, so there'll be various problems to sort out along the way. One thing we'll be keen to do is to preserve "compatibility" so that the thousands of dynamic components that have already been produced will continue to work properly in the future as Java evolves. But this kind of work wouldn't be the same without interesting problems to solve.

Footnote: if you work in the computer industry and you read this far: well done! You're probably used to reading complex documents that hardly anyone, in terms of world population, can understand. You and I have probably written a fair few too. But here I've tried to be as simple as possible so that "normal" people can understand. I think this is important because some of the systems our industry produces also need to be used by normal people and, on the whole, we need to get a lot better at that.