On 2018-06-14 12:49, Magnus Ihse Bursie wrote:
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.
I agree that include would have been easier to use, and I was initially
trying to implement it that way, but couldn't come up with an effective
solution in make. You need to identify all source files that have locale
suffixes and only filter among them. With the exclude, at least the
build logic is reasonably straight forward since the user defines the
locale strings that define a translation that warrants action.
This is why I added a test that uses include logic, hoping that the
combination would prove resilient enough to catch such changes. The test
is still a bit brittle since it can easily catch false positives.
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.
Thanks!
/Erik
/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
