It is possible for attributes of array type (for example, [Ljava.lang.String; ) to be written to as well as read from. So, it is possible, for instance, to update a queue's array of aliases using the MQe JMX interface.
However, there are limitations to the manner in which some adapters allow the user to make such updates. For example, the Sun RI HtmlAdaptorServer adapter will only provide an array for the update which is of the same dimensions as the current array. Thus, if a queue has no existing aliases, the array for update will be of size zero, and hence no new alias can be added for the queue using the queue alias attribute. However, in this case, an alias can be added using the addAlias() operation.
If a queue has two existing aliases, then the array provided for the alias attribute update is of size two. One or both of the two aliases can be changed using the writable array. However, some adapters do not allow the user to clear the contents of the array cells and pass back an array containing empty string(s). This will cause an exception. Hence these adapters will only allow an update which keeps the number of existing aliases constant.
Since these are limitations of specific adapters only, we have decided to allow such array attributes to be updated where appropriate. The alternative would be to force users to use operations for adding aliases rather than using the attribute update potential.
This specific example may also be extended to situations where the capability of the adapter or connector does not match the capability of a programmatic interface. We are not in a situation to predict such limitations in advance and hence there may be features of our implementation which are not ideally suited to some adaptors and connectors. We have decided against constricting the functionality of our instrumentation layer to match the capabilities of specific adapters.