Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

2020-07-21 Thread Mark Davis ☕️
One option is to have a fast path that uses char functions, up to the point where you hit a high surrogate, then drop into the slower codepoint path. That saves time for the high-runner cases. On the other hand, if the times are good enough, you might not need the complication. Mark On Fri, Jul

Re: [15] RFR: 8244152: Remove unnecessary hash map resize in LocaleProviderAdapters

2020-05-07 Thread Mark Davis ☕️
> (int)(tokens.countTokens() / 0.75f) + 1 > (tokens.countTokens() * 4 + 2) / 3 if you want A * X / Y, rounded up, you can use (A * X - 1 ) / Y + 1 eg where X/Y = 4/3, 0 => 0 1 => 2 2 => 3 3 => 4 4 => 6 ... Mark On Tue, May 5, 2020 at 9:48 AM Peter Levart wrote: > Hi Naoto, > > On 4/30/20 1

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

2020-05-07 Thread Mark Davis ☕️
I wouldn't worry too much about over 2^29 either. However, the number of possible valid language tags is much larger than people think, since any combination of multiple variants can occur). So even not counting the locale extensions, it is over 2^129 (my rough calculation). Mark On Tue, May 5,

Re: Turkish Time Zone name string and translation

2019-11-18 Thread Mark Davis ☕️
You'd have to look at the spec. For most names a pattern plus the country name is used. That can be overridden with a non-composed name where needed. {phone} On Sun, Nov 17, 2019, 21:50 Martin Buchholz wrote: > I've always wondered how the timezone-related translations are managed. > CLDR seems

Re: Turkish Time Zone name string and translation

2019-11-18 Thread Mark Davis ☕️
lized > names from the legacy COMPAT locale data are being used. I will look > into it. > > Apart from this, what Letu found out stands by itself as a bug in COMPAT > provider. > > Naoto > > On 11/17/19 11:16 PM, Mark Davis ☕️ wrote: > > You'd have to look at the spec