Would it have been to problematic to reverse the the logic, i.e. having
a "include translation" rather than an exclude? Feels more brittle; if
someone adds a translation the exclude list needs to be updated. Also, a
include mechanism could possibly be used, much simpler, by someone who
only wants to build e.g. a chinese jdk.
But I realize the contraints by the somewhat odd request from the bug
report, to deliver just a subset of the available translations. So I'm
okay with the patch.
/Magnus
On 2018-06-14 20:52, Erik Joelsson wrote:
Hello,
Here is a new version of the patch:
http://cr.openjdk.java.net/~erikj/8204973/webrev.02/
Changes from last time:
* Made the regexp for finding locales more correct. It still does not
try to match 3 letter language strings because doing so triggers a
large amount of false positives in our souce tree.
* Added another accepted locale (en_US_POSIX) that is now matched by
the improved regexp.
* Added more locales to the exclude list as they were now discovered
by the improved regexp.
/Erik
On 2018-06-13 12:47, Erik Joelsson wrote:
Hello,
Oracle will reduce the number of languages that it maintains
translations of JDK resources for. The current translations will
remain in the source for now, but we need a way to filter out a set
of translations at build time so that we only include the ones we
support. This patch adds such a configuration option. It also changes
how Oracle builds by using the option to exclude all translations
except English, Japanese, Simplified Chinese and Traditional Chinese.
Anyone else building OpenJDK will by default include all translations
present in the source, just as before.
I added a test that verifies this for builds with the "IMPLEMENTOR"
field in the release file set to "Oracle Corporation". The test will
not be run for other OpenJDK builds.
I had to modify an existing test for java.logging which used various
translations to verify localized log messages to only use
translations that Oracle chooses to include.
Since this is the second test that specifically verifies build
behavior, I moved the previous such test together with this new test
into a common top level test directory "build", under the jdk test
root. I put these tests in the jdk tier3 test group.
I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically
looked for tests that use the java.util.Locale class and ran them
locally.
Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8204973
/Erik
