Map FreeText to CharSequence instead than InternationalString


ISO 19115:2014 said explicitly that CharacterSequence having a FreeText domain shall be internationalizable. GeoAPI supports internationalization with the InternationalString interface. The vast majority of character sequences in ISO 19115 are FreeText, which result in InternationalString about everywhere in metadata interfaces.

However users are not forced to internationalize their metadata - it is supposed to be a choice. Very often, the text is a non-internationalized String. The current API design force users to wrap their string in an InternationalString for every metadata object.

The proposal is to map FreeText to java.lang.CharSequence instead. Given that both String and InternationalString extend CharSequence, that would leave the choice to users.

Backward compatibility

This is a compatible change (at the source level) for implementors, since methods returning an InternationalString will still be valid even if the return type in the interface has been changed to a super-type. Implementors will need to recompile their libraries however.

This is an incompatible change for users who expected InternationalString instances. However in the majority of cases, the users were just invoking the toString() method. The later is explicitly defined in the CharSequence parent interface, which make the transition from InternationalString to CharSequence easier - the need to perform "if (x instanceof InternationalString)" checks is expected to be rare.

Nevertheless because of incompatibility, such change could be done only in a GeoAPI 4.0 release. Since the upgrade to ISO 19115:2014 and the move from JSR-275 to JSR-363 may cause other incompatible changes anyway, we may take the opportunity for making the replacement described in this task.