Openfire uses properties as implemented by the JiveGlobals and JiveProperties classes. These classes provide persistence, as well as event listeners for properties.
Property values are based on Strings, but utility methods exist to work with numeric and boolean based properties.
At times, a property is used to store a list of values. As there is no utility method for working with lists, these lists are typically stored in a token-separated string. All kinds of oddities pop up here:
Although comma is common, the separator character can vary from implementation to implemementation
Values can, but are not always, surrounded by whitespace.
Values can, but are not always, enclosed by quotes. Or double-quotes.
This all leads to various variants of boilerplate code, which is getting messy. Instead, Lists should become a first-class citizen of the property implementation.
Properties are hierarchical. Their dotted notation implies a tree-like hierarchy, where property A.B.C is a child property of A.B, and a sibling of A.B.D.
A collection could be stored in individual child properties. The natural ordering of the child property name could be used for sorting.
There's some danger of overlap between child properties used for a collection, and child properties that are unrelated to the collection, but in practice, that should not occur. It is unlikely that someone uses a property to store one value, and a child property of this property for another value. A warning in Javadoc should be sufficient protection against this.