RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

[Paul Sandoz]

On May 20, 2015, at 7:32 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>> Just had an idea... I believe static intializers are executed in textual order. So you could have a static code block after all static UnicodeBlock instances have been defined that asserts the size == 510 (or is <= 1024 * 0.75). In that case i would argue a static final representing the expected size is justified.
>>  Then your test can derive the initial capacity from mapSize.
> 
> I've just checked www.unicode.org to see how many new entries we can expect in the nearest future.
> Unicode 7 will add 32 new blocks (96 with aliases): http://www.unicode.org/versions/Unicode7.0.0/
> Unicode 8 will add 10 more blocks (30 with aliases): http://www.unicode.org/versions/beta-8.0.0.html
> 
> So, after implementing Unicode 7 and 8 in java we're going to have 510+96+30 = 636 entries in the map.
> The internal array of size 1024 (as it will be, if (510/.75 + 1) is used for the initial capacity), is going to be sufficient to hold all these.
> 

Nice investigation. What you have written above would be useful in a comment on the map.

Paul.

> So, I think we're going to be good for a few next years.
> And once the number of entries exceeds 768, the resgression test will warn us.
> 
> 
> Here's the update with the corrections to the test as you suggested:
> http://cr.openjdk.java.net/~igerasim/8080535/03/webrev/
> 
> Sincerely yours,
> Ivan