In case you haven’t quite figured it out, the above RFC stands for Request For Clarifications in this case — as in, this post is meant to pretty much ask the tinterweb population out there if they know anything about this. (My searches so far have proved unsuccessful — though I am known to be a rubbish googler, sorry!)

Also, this question relates to a class (well, interface really) in the standard JDK — I’ve discovered this using JDK 1.6, however, it seems this is still just as vague in Java 7 — so as of now, this is rather an open question I’d say…

As you might have guessed from the name of this post, the question concerns the DynamicMBean interface in javax.management package. The JavaDoc for JDK 1.6 is here and the one for Java7 is here. More to the point, the question is regarding the getAttributes() method.

As per JavaDoc, the signature of the method is this:

public AttributeList getAttributes(String[] attributes);

And the JavaDoc explains it this way:

Get the values of several attributes of the Dynamic MBean.

Parameters:

attributes – A list of the attributes to be retrieved.

Returns:

The list of attributes retrieved.

See Also:

setAttributes(javax.management.AttributeList)

As you can guess, by now my question actually affects now the setAttributes() method too! But first things first, right 😉

If I am to read this correctly, this to me reads “convenience method to repeatedly call getAttribute() on each string in the array passed in” — or at least that’s the way I understand it (maybe, and this could be a crucial point???!!!, I am wrong?). So when implementing the DynamicMBean interface, your code for getAttributes() would look like this:

public AttributeList getAttributes(String [] attributes) {
  AttributeList lst = new AttributeList();
  for( String a : attributes ) {
    lst.add( new Attribute(a, getAttribute(a)) );
  }
  return lst;
}

As you will notice, the only slight difference from getAttribute() which returns the value of the attribute itself is that here we return a list of Attribute, which means we have to wrap up each attribute name/value in an Attribute instance and store it in the returned list.

You’d think that’s the case… however! The bloody getAttribute() function has this signature:

public Object getAttribute(String attribute) throws AttributeNotFoundException, MBeanException, ReflectionException;

And if you do any validation of attribute names in your code, quite likely you will throw at least an AttributeNotFoundException for err’d attribute names — please tell me you do that rather than return null, right? Which then begs this question: in the above loop, what do we do when getAttribute() throws an exception???

Do we simply store a null in that position in the AttributeList (which is just a glorified ArrayList<Object>)? Otherwise, if we don’t store anything for a failed call to getAttribute() we will have less values in the returned AttributeList than in the input String array and that makes it impossible to tell which value corresponds to which attribute?

Do we throw a RuntimeException when we encounter the first wrong attribute? (In other words when we encounter the first exception being thrown by getAttribute()?) Do we build a list with all the failed getAttribute() calls? Do we do a little dance? Make a little love? Get down tonight? 🙂

Focusing now on setAttributes, as I said, the question relates to this as well now — the JavaDoc reads:

Sets the values of several attributes of the Dynamic MBean.

…

Returns:

The list of attributes that were set, with their new values.

That’s pretty vague if you ask me, because again, if you assume this is a repeated call to setAttribute() for each attribute in the list passed in, then it needs to be said that setAttribute() can throw any of these:

• AttributeNotFoundException
• InvalidAttributeValueException
• MBeanException
• ReflectionException

So again, is it safe to guess that if setAttribute() throws one of these inside setAttributes() we will not be adding the attribute to the returned list of attributes? It seems (though not that clear) that we can only return the attributes which were set, and not the ones which failed… But does that mean that we have to assume that the caller will imply based on this that the other attributes failed? There is no mention of that — so we can just as well assume that the caller is expecting perhaps a RuntimeError if something fails?

So to sum it up: are we ok to return less items or add null where things fail? Or are we to throw RuntimeError‘s — if so, which are the preferred ones to be thrown? IllegalAccessError? NumberFormatException? NullPointerException? (The list can go on…)

Still a bit in the dark here — for now I’ve decided to throw some random IllegalArgumentException — since there is no spec around this, I thought it to be just as good as any others but like I said in the opening of this, I am so so so keen to hear some thoughts on this!

Thank you all in advance!