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
