Category Archives: apache

Whatever Happened to Mr. Garibaldi?

It has been a long while since I posted, and a lot has happened since then.

The Apache Incubator Kato has been retired and lots of inactivity. This was not surprising, there just wasn’t the will for the project to start again, and in open source an unwanted project dies, and rightly so. While I would have liked to, commitments at work at IBM and the birth of my daughter conspired to prevent that from happening.

I have also moved from Winchester to Cambridge, changing from working at IBM to working at ARM, which changes my perspective on things too, and my paymaster.

So what’s in the future? I will be learning lots about the ARM architectures – particularly ARMv8 and the 64bit variant of that. I have ideas for some projects, but more on that in the future.

The Long Dark

If there is one thing I’ve learned from the Kato project, it’s that open source software needs a community with the motivation to participate. Unfortunately with the acquisition of Sun by Oracle, JSR-326 has been held up as we really needed Sun/Oracle to participate. Of course, the Apache Kato incubator is not JSR-326, but the two were tied together, and the outcome of Kato was to produce JSR-326’s reference implementation.

So what has happened after the 0.1 release of Kato? Well, conversations have been had between representatives from IBM and Oracle, led by Steve Poole. Events have been progressing extremely slowly, as Java debugging in the manner of Apache kato hasn’t been a huge priority – Java 7.0 has been the highest priority. My hope is that the once Java 8 gets the focus JSR-326 and Kato will get some attention. Oracle have apparently assigned someone to work on this – we look forward to hearing from him.

Robert Burrell Donkin has continued to show superhuman levels of patience with his encouraging words. Even with months and months of activty he continues to encourage us. The original goals of this project were worthy enough, but I believe it would have been better for us to develop the technology, open-source it for collaboration in an Apache Incubator, and then consider standardizing it. One of the options considered was to ignore the JSR for now and continue developing cool technology – I would like to explore that idea.

Personally, there has been a lot going on since 0.1. In IBM I’ve occupied three different roles (none of them in JVM technology). I also managed to get married and my baby daughter was born in June this year! So doing open-source projects in your free time has proven difficult when free time is in such short supply.

So, to the future:

I believe JSR-326 will probably be completed. However, it would be advantageous if we reevaluated it’s goals in light of developments since this project started. One area we could consider addressing is debugging in cloud environments.

I’d like to see Apache Kato decoupled from JSR-326 if the JSR does not seem likely to continue – a new JSR could be submitted if the Apache Kato technology proved valuable enough for standardization.

OpenJDK will continue as is, and we need to consider our relationship with it carefully. Technology embedded in the JDK would be GPL licensed. The code that tooling would use to interact with OpenJDK would be best distributed with a permissive licence, i.e. Apache, so that tools development could be collaborated on. I imagine this will turn out to be a mine field, so we shall see.

So here’s to the next quarter – may it be more interesting that the last 6!

A Voice in the Wilderness

Well, January was an interesting month.

The Kato project had some much needed input from Lukasz from Poland. One of the more useful things about the Apache Kato project is it provides an API for accessing hprof files. Previously each tool would need to write its own implementation of an hprof file reader.

The kato project includes a little tool called “KatoView” that allows hprof files to be queried on a command line. While it’s usefulness is limited, there are some useful things that can be done.

I am learning to be a release manager for the project. Apache operate in its own unique way, and it is taking some getting used to, but one of the fundamental processes is the Voting process.

Last week I asked the Incubator project management to vote on whether or not Kato’s first release should be allowed out into the wild.The voting process is roughly as described here. An email is sent with the subject “[VOTE] subject to vote on”, a description of what is being voted on and an announcement of when the vote is to be closed. This should be a minimum of 3 days. People will then vote +1, 0 or -1.

+1  is used to indicate when someone supports the proposal.

0 is used when the voter is neutral.

-1 is when the voter is opposed to the proposal.

Often voters will have additional comments, especially if -1 or even 0 votes are submitted.Generally at least 3 +1’s are required. Under some circumstance -1 constitutes a veto.

The Apache Kato incubator has few active participants, and with insufficient votes the “lazy consensus” approach is often used. i.e. lack of votes constitutes tacit support.

1 day to go on the M1-incubating release. Fingers crossed for lots of +1s 🙂