index page provides a pretty good explanation of what OpenArm
is (or, at least, what it intends to become). But it doesn't answer the question "Why?" Why bother
implementing the Open Group's ARM specification in Java?
The short answer, of course, is "Why not?" Flippant one-liners don't get us any closer to an
explanation, however. The explanation itself is really quite simple: because there is no other
freely available implementation of ARM.
ARM itself is a pure specification. The Open Group does not provide a reference implementation -- they
don't provide any kind of implementation at all. Traditionally, they've left that for the various
commercial vendors who are members of the working group. And there are a number of commercial,
proprietary implementations of ARM, notably from Tivoli and HP. These implementations are fairly
The market hasn't complained about that, however. The typical "user" of ARM -- an organization which
uses it to instrument an application to gather performance information -- is a Fortune X000 company.
These folks are accustomed to shelling out large sums for "enterprise" class software, and the vendors
have seen no reason to package or market their ARM tools as anything but.
I have reason to complain, however. I had the opportunity to work with ARM at a major bank, and was
involved in both evaluating tools and instrumenting applications. Although I've come to regard
the ARM API as a bit "hidebound" by its procedural, C-oriented roots, it's nonetheless THE standard
in this problem domain -- the only one of its kind that I'm aware of. Yet its use is limited to those
whose pockets are deep enough to afford the Big Vendors and their Big Tools.
I think that's unfortunate. I believe these circumstances have hindered (or at least slowed) the
widespread adoption of ARM. ARM has virtually zero "mindshare" among the typical "corporate"
developers who stand to profit the most from it. I've never met another developer, in the flesh,
who knew what ARM was, let alone used it. I believe a big part of the reason why that's so is that
it is virtually impossible to obtain a "working copy".
You can't just download the interfaces (or the C headers, for that matter) from the Open Group's Web
site and "take it for a spin". Without a reference implementation to play around with, the barrier
to entry for the curious hacker is simply too high. People are just too busy to spend the day or so
it takes to hack together a simple implementation of the ARM interfaces, just so that they
begin to evaluate it for their needs.
Recently, I found myself in a situation where it was abundantly clear to me that the application I
was working on could profit enormously from being instrumented with ARM. I wasn't the only one to recognize
the need, within our project -- it was plainly obvious. Thus, several other clever, well-meaning
developers in our team had already done a good bit of work re-inventing that wheel, with a few
customisations for log4j. Using these home-brewed tools, they had already begun to instrument the
application, using the custom logger to trace the beginning and end of key method calls.
But their efforts were haphazardly applied, and inconsistently executed. Apart from that, there was
a growing awareness that other parties had an interest in similar information -- operations, for example.
Because of that, parallel efforts had begun, to try and "mine" the existing log files for similar information
with Perl scipts, which then massaged the data, to present it in a Web portal.
These various, disconnected efforts needed to be coordinated, and the opportunity to use a standard, both
in terms of interface and data format, was screaming to be noticed. So I suggested that we should
instrument the application using ARM.
But how? Not havig the budget of a Fortune X000 or a dot boom startup company available to us, how
was my project supposed to go about using ARM? Without the deep pockets of such a company, and
therefore no chance of buying one of the Big Tools, how could we nevertheless use ARM? Maybe there
was just no alternative to ad-hoc, haphazard, half-baked, incompatible solutions?
OpenArm is my answer to this dilema -- I decided to try to end the Big Vendor's monopoly on ARM
I don't have any illusions about the scope of OpenArm -- competing directly with the Big Vendors is
not a goal. However, it isn't my intention that OpenArm be a toy application, either. OpenArm will
attempt to be a full-fledged, useful implementation of the ARM standard. Only time will tell if we
succeed. It's certainly worth a try.