How about letting CountryCode implement an interface.

[mihxil]

I would like that CountryCode implements some 'Region' interface. This would make it possible to make more implementations, like e.g. 'former countries' (I'm setting up something at https://github.com/mihxil/i18n-formerly-assigned).

I suggest something like this:
https://github.com/mihxil/nv-i18n/blob/master/src/main/java/com/neovisionaries/i18n/Region.java

How would you feel about something like this?

[derekmahar]

I had a similar idea when I created CustomCountryCode as an interface for CountryCode in order to implement class StandardOrUserAssignedCountryCode to accommodate user-assigned country codes.

[GuiSim]

I'd use this right now for an API that returns XX, which can be used to denote an unknown country (why they didn't use null, I do not know).

[mihxil]

I was rather hoping that @TakahikoKawasaki would react how he'd see something like this. I can make a pull request, but may be it's better to know beforehand what kind of reaction to expect.

[mihxil]

Actually I was thinking, there is a possible other approach, and I made a new project which provides this 'Region' interface along with a few implementations (one of them or course based on nv-i18n).

So, in this way we actually can add the Region interface without having to add it here. I made it pluggable via java service provider interfaces. So you could simply made a 'RegionProvider' and make it return whatever extra Regions you'd like.

I hacked this up in a few spare hours, so it's not yet quite finished:
https://github.com/mihxil/i18n-regions

[derekmahar]

I think this approach makes sense. As an enumeration, the existing CountryCode implementation does not allow clients to add new country codes. It is essentially closed to extension. By introducing interface Region, you open CountryCode to extension through custom implementations.

[derekmahar]

What is the purpose of RegionProvider?

[mihxil]

I takes the roles of static methods, like .values() and getByCode. Using java's `java.util.ServiceLoader' to access all registered implementations.

[derekmahar]

I noticed that https://github.com/mihxil/i18n-regions assumes Java 8, but nv-i18n does not. This would introduce a compatibility issue for clients still using Java 7 and earlier.

[mihxil]

Yes, but really? Java 7 was end of life a few years ago, wasn't it? I actually considered making it java 11!

But well, if somebody really considers this an obstacle I'd gladly consider making it java 7 compatible. I suppose that would be relatively simple.

[mihxil]

I in the end didn't make it java 7 compatible. The code depended on Stream-api's and I think it would be silly to make everything different just to still be able to support java 7.

It will be java 8+. I tried to even support java 9 module-info.java as good as possible.