I started this week by adding an implementation of the runtime bean, which allows the user to probe for all the sorts of information about the virtual machine. Well, I say all sorts, but most of what’s available from the beans is little more than a gathering together of stuff that is already accessible (lots of the runtime bean stuff just points to named properties). The garbage collectors and memory managers look a bit more interesting (for one thing, you can then see multiple collectors or managers), but the designers of these seem obsessed with counting the time it takes to do things. With the runtime bean, will we now see people boasting about their virtual machine uptime in the same way they do about their physical machine?

With some great feedback from the folks hanging about on IRC (including Michael Koch, Christian Thalinger and Tom Tromey), we sketched out a rough idea of the required native hooks and a good choice of properties for obtaining the boot class path (which e.g. CACAO and gcj already supply a sun.boot.class.path). The native hooks for the runtime bean only number two (one for arguments and one for start time), but no doubt the others will bring more.

I’m now working on trying to turn the two existing beans into dynamic beans, before starting to hack on an implementation of these native methods in gcj. Making them dynamic beans will enable the attributes to be obtained dynamically from the bean and will also provide the translation support required in the management factory documentation. However, this seems to require a lot of classes in javax.management (and we only had one to start with, Attribute, which Audrius Meskauskas put together). These classes are clearly designed for being accessed from languages over than Java, as they define a lot of classes simply to wrap stuff that already exists. For instance, the attribute list is just an array list; fine in Java but other languages don’t have such predefined collections. It also has its own exception hierarchy, which results in me having added nine classes to javax.management so far, and still not even having the dynamic mbean interface; these are merely its dependencies! But still it means our percentage is looking more respectable…