On May 20, 2015, at 7:32 PM, Ivan Gerasimov <ivan.gerasi...@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
