[12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect
Claes Redestad
claes.redestad at oracle.com
Tue Dec 11 22:31:21 UTC 2018
Hi Naoto,
while the here fix looks good, I can't help wondering why the map isn't
final?
/Claes
On 2018-12-11 19:59, Naoto Sato wrote:
> Hi Ivan,
>
> Thank you for the review.
>
> On 12/11/18 10:49 AM, Ivan Gerasimov wrote:
>> OptimalCapacity.ofHashMap uses the initialCapacity to verify that a
>> HashMap created with that initialCapacity will not reallocate its
>> internal array after inserting the factual number of elements.
>>
>> So, if one day the number of entities is increased, but the constant
>> NUM_ENTITIES is not updated, then the test will catch it.
>
> Actually the reason I am fixing it is that, the test did not detect the
> discrepancy with Unicode 11 upgrade, where it just increased the entry
> numbers by the true block increases (11 blocks), without adding their
> aliases.
>
> ---
>
> --- a/src/java.base/share/classes/java/lang/Character.java Wed Nov 14
> 13:15:54 2018 +0100
> +++ b/src/java.base/share/classes/java/lang/Character.java Wed Nov 21
> 14:24:31 2018 +0530
> @@ -43,7 +43,7 @@
> * a character's category (lowercase letter, digit, etc.) and for
> converting
> * characters from uppercase to lowercase and vice versa.
> * <p>
> - * Character information is based on the Unicode Standard, version 10.0.0.
> + * Character information is based on the Unicode Standard, version 11.0.0.
> * <p>
> * The methods and data of class {@code Character} are defined by
> * the information in the <i>UnicodeData</i> file that is part of the
> @@ -681,11 +681,11 @@
> */
> public static final class UnicodeBlock extends Subset {
> /**
> - * 638 - the expected number of entities
> + * 649 - the expected number of entities
> * 0.75 - the default load factor of HashMap
> */
> private static Map<String, UnicodeBlock> map =
> - new HashMap<>((int)(638 / 0.75f + 1.0f));
> + new HashMap<>((int)(649 / 0.75f + 1.0f));
>
> /**
> * Creates a UnicodeBlock with the given identifier name.
> ---
>
> However, the HashMap allocates the entry size to the nearest power of
> two number, i.e., 1024 for both numbers 649 and 667. Thus the test
> passes even if there is discrepancy.
>
> Naoto
More information about the core-libs-dev
mailing list