I had a very interesting conversation yesterday with Simon Phipps, Sun's Chief Open Source Officer. You can read some of it here at IT Pro .

Sun's Chief Open Source Officer Simon Phipps has announced the next stage of the open sourcing of Java in London this week, adding Java ME to the road map. Open source versions of both Java ME and Java SE should be available by the end of the year.

While there were no actual dates confirmed, Phipps went into more detail on the open source roadmap for Sun's various software platforms. Describing it as a gradual process, he detailed Sun's commitment to providing an open source software stack, from OS to Java, and in the future, its middleware.

We also talked about the missing element in many Open Source projects: governance.

While one of the keys to Open Source is the license, another is just how the project is run. And Simon sees one big problem facing many open source projects.

It's all very well being open source, but with only one person with commit rights (the ability to make changes to the code) to the code base, if the project becomes successful, they're going to become overwhelmed very quickly. Things get worse when commit rights are concentrated in a single project. A project run that like that (and there are many many of them, including some very high profile ones indeed) is more like Microsoft's shared source programme than anything else. There have even been cases when experts on a piece of code have left the company that sponsors the project, and have immediately lost any rights to working with the codebase...

The really successful projects, like Linux and Apache, have distributed commit rights, and a range of people from many different organisations adding code. That's what Phipps wants to do with Sun's open source projects. Open Solaris is certainly successful, and has spawned several different distributions (including one that mixes Debian with a Solaris kernel), and he hopes to the same with Java.
Cross Posted to A New IT World

I spent last Friday morning braving the delights of Highway 17 over the Santa Cruz mountains in the rain at Azul Systems' offices next door to Google in Mountain View, learning lots of interesting stuff about their Vega processor and their network attached processing tools, including just how they do "pauseless garbage collection".

You can read about some of my morning at The Register:

Adding storage to a network is straightforward; adding processing power tends to involve a lot more complexity. This is something Azul Systems aims to change. Following the recent announcement of its second generation Vega processor, is today’s news that BT will be using the company's processing appliances to handle both its existing web applications, as well as providing the foundation for a utility computing farm – part of BT’s 21st Century Network.

The Azul platform is more than just a box you connect to your network, which replaces software virtual machines. It’s also a set of tools for managing application performance and handling how you bill the rest of the business for CPU usage. Mainframe administrators will be familiar with these techniques, but they’re still new to the arrays of application servers that now run many of our businesses. Being able to bill for actual CPU and memory usage is a key part of any utility computing platform – whether it’s Sun’s $1 per CPU per hour or an IT department billing the rest of the business for application operations.

They've got quite an impressive server room too, especially when you realise that each of those boxes has 384 cores - so that's the equivalent of 9600 CPUs in this rack alone:



Not bad - and what's more important, not too power hungry.

An interesting announcement from today's sessions at BEA World here in Santa Clara: the development of a deterministic version of the JRockit JVM - and the announcement of a real time edition of the Weblogic application server.

It's especially interesting as it means that there's finally a way of getting a real-time Java. Java works well in most circumstances, but its garbage collection is non-deterministic. You cannot control when, or for how long, the JVM runs its garbage collection routines. While this is one of Java's strengths (there's no need to write memory, stack and pointer management code), it's also one of its biggest weaknesses, and disqualifies the language from many applications.

You can't use Java for large-scale trading applications, as this means that there's no way of ensuring repeatable transaction timings - as the JVM could quite happily take processing cycles at any time and for any length of time. By making garbage collection deterministic (and controllable), BEA can deliver transactions in fixed times - exactly what the financial sector is looking for in its trading applications. It'll also make things easier for telcos and help them manage their switching fabric more effectively.

Now, will we get a deterministic version of the .NET CLR?