<i18n dev>  RFR: 8159781: jlink --include-locales fails with java.util.regex.PatternSyntaxException
masayoshi.okutsu at oracle.com
Tue Jun 21 02:53:07 UTC 2016
If the long pattern string is avoided, it'll be unnecessary to use "%%"
and replaceAll? I'm also concerned to keep concatenating strings to
produce a long string (rather than using a StringBuilder). Would that be
the reason to put -verbose:gc in the test program? Use of List<String>
will simplify the processing as Mandy suggests.
On 6/21/2016 7:00 AM, Naoto Sato wrote:
> Here is the updated webrev:
> On 6/20/16 8:18 AM, Naoto Sato wrote:
>> Hi Mandy, thank you for the review.
>> INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
>> patterns are constructed at the runtime with the passed argument, by
>> replacing "%%" with locale patterns. So I think it is less complex to
>> handle it as the current way.
>> I will modify the "regex:" prepending as you suggested.
>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> Decided to fix this separately from the other include locales issues.
>>>> Here is the bug and the proposed fix:
>>> The change looks okay. This can be converted to use
>>> ResourceFilter::includeFilter(List<String> patterns) rather than
>>> building a comma-separated patterns string. That means META_FILES and
>>> INCLUDE_LOCALE_FILES can be made as List<String>. You have an option
>>> to prepend “regex:” when constructing the patterns to pass to
>>> ResourceFilter. I think that’s a good clean up to do.
More information about the i18n-dev