RFR: JDK-8204973: Add build support for filtering translations

[Erik Joelsson]

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
>>>
>>
>