A DESCRIPTION OF THE REQUEST :
TabularDataSupport uses an internal HashMap for keeping CompositeData rows. As a result, row values are sorted by hash codes. However, in some case, it's critical that TabularDataSupport provides a view of rows in the actual insertion order.
I propose adding a new constructor accepting a helper  customer  which can figure out how values should be presented.

JUSTIFICATION :
For example, when displaying interceptor details for a given managed endpoint we need to see them in the correct order. Displaying then in the random order will mislead the operator.


CUSTOMER SUBMITTED WORKAROUND :
One workaround is to pass a CompositeData order item with each row which would let a customized client to sort rows properly. However this would require us shipping client-side jars for all popular consoles which may not be possible
Anotehr one is to format a row in a String and pass an array of rows but this is much less elegant and may not be ideal either
Posted Date : 2005-10-10 08:44:48.0

N/A

TabularDataSupport could have a constructor that accepts the Map to use to keep the internal data.  Then you could pass a LinkedHashMap if you want insertion order, or a TreeMap with an appropriate Comparator if you want some key-based order.
Posted Date : 2005-10-14 14:34:13.0

Alternatively TabularDataSupport could just use a LinkedHashMap always, and users can get the order they want just by inserting the rows in that order.  This will probably be enough for nearly everybody.

The only drawback is that LinkedHashMap has only existed since version 1.4 of the Java platform.  If we make this change in version 7, then code running on versions earlier than 1.4 will no longer be able to deserialize TabularDataSupport instances coming from version 7.  But given that 1.4 came out in 2002 and that TabularDataSupport is not indispensable I think we can live with that.  We could define an undocumented system property that would cause TabularDataSupport to continue using HashMap if we really wanted to avoid even this unlikely case.

MXBeans should be reworked at the same time so that the translation back from a TabularData to a Map<K,V> constructs a LinkedHashMap.  This means that if you start with a SortedMap or a LinkedHashMap then mapping to MXBean types and back will preserve the original order.  This does not need to be governed by the system property just mentioned because the resultant Map is not intended to be serialized.
Posted Date : 2008-06-20 13:52:58.0