Joperties interprets objects based on their runtime type. It does that by looking up an internal Map of Interpreters. The list of supported classes gives you a list of the classes for which Interpreters have been registered by default in Joperties. One special Interpreter, not registered for any class, is the CollectionInterpreter. The reason this Interpreter is not registered for a type, is that the class Collection is generic. It has no runtime type. You can have a Collection<String> or a Collection<Color>. An example of its usage was given in a complicated example
It is very important to be cautious when using Collections in Joperties. The reason is that the Interpreter is using the separator ">>" to separate individual entries in the Collection. The problem is apparent in the RadialGradientPaint and in the really complicated example.
The RadialGradientPaintInterpreter is using the CollectionInterpreter to interpret arrays of floats and Colors. But it modifies the separator used by those CollectionInterpreters, changing ">>" to "<<" in order for the RadialGradientPaint to be used in turn in a Collection.
It is important to change this separator yourself in any custom Interpreters you create for the same reasons. To that end, the CollectionInterpreter class provides the method setCollectionSeperator() which changes the String used to separate entries.
▲ TopJoperties currently treats all subclasses of Collection as a Collection. So, for instance, you can supply a Set<Color> but when you retrieve it, you must treat it as a Collection<Color>. If you really want to, you can create your own Interpreters for specific subclasses of Collection.
▲ Top