RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base
mandy.chung at oracle.com
Thu Sep 8 01:37:34 UTC 2016
> On Sep 7, 2016, at 6:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> Hi Mandy,
> Although avoiding the hardcoded pathname is good, it is specific to the BreakIterator implementation of the COMPAT provider. So I am not sure making a generic SPI would be needed here.
I was thinking of one of the internal services that jdk.localedata currently provides.
> Anyway, this split package issue is blocking Alan's push, so I'd like to push the change as it is. We can get back to this later.
I agree this can be cleaned up as a separate issue.
152 InputStream is = module.getResourceAsStream(
153 ("jdk.localedata".equals(module.getName()) ?
154 "sun/text/resources/ext/" : "sun/text/resources/") + dictionaryName);
It may be easier to read if line 153-154 are moved and assign to a separate variable. Otherwise, looks fine.
> On 9/7/16 5:17 PM, Mandy Chung wrote:
>> Hi Naoto,
>> Is there an alternative to get back the pathname of the resource e.g. adding a method in existing internal SPI to avoid hardcoding the module name and the resource pathname.
>>> On Sep 7, 2016, at 3:56 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>> Forgot to include jlink plugin changes. Here is the updated webrev:
>>> On 9/7/16 3:03 PM, Naoto Sato wrote:
>>>> Please review the changes to the subject bug:
>>>> The proposed fix is located at:
>>>> The change is simply to move those 3 resources under
>>>> sun.text.resources.ext package so that it won't cause the split package
More information about the core-libs-dev