fix for jpms by remove use of ResourceBundle.Control

[aanno]

I observed the following

1. The use of ResourceBundle.Control with the Java Platform Module System (jpms) is not possible. In Java >=9 the following method is present in ResourceBundle:

    private static void checkNamedModule(Class<?> caller) {
        if (caller.getModule().isNamed()) {
            throw new UnsupportedOperationException("ResourceBundle.Control not supported in named modules");
        }
    }

2. ResourceBundle *.properties files in epubcheck are UTF-8 encoded.

Hence this pull request will (a) eliminate the use of ResourceBundle.Control and unify the loading of *.properties files to enhance the compatibility of epubcheck with jpms.

Review und comments are appreciated.

Kind regards,

aanno

[rdeltour]

Thanks for the PR @aanno!

I wasn't aware of this change in Java 9 and the JPMS limitation about ResourceBundle.Control. +1 on the objective to improve the compatibility of EPUBCheck with JPMS.

The suggested workaround might be a bit naïve compared to the default logic implemented by ResourceBundle however.

Specifically:

• the logic to compute the list of locale candidates is more complex and includes some special casses, see ResourceBundle.Control#getCandidateLocales in Java SE 8
• ResourceBundle caches the loaded bundles, which does not seem to be the case here

Besides, as far as I understand (I'm not very familiar with JPMS) this would still not allow another named module to provide localized properties for EPUBCheck (or does it?).

In any case, it seems that using ResourceBundle.Control raises an UnsupportedOperationException only when passed as an argument to one of the ResourceBundle#getBundle(…) methods. But its API can be used directly, for instance to get the list of candidate locales and locale fallbacks.

Before merging anything, I'd like to explore the possibility of implementing something closer to the ResourceBundle logic, using ResourceBundle.Control#getCandidateLocales(…) and possibly using naïve map-based caching.

I'm removing this PR from the next maintenance milestone, and I'll try to propose another PR (as an alternative to this one) for the next after.