-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b07
The current HexFormat defines an Enum to represent LowerCase and UpperCase
class HexFormat {
private enum Case {
LOWERCASE,
UPPERCASE
}
}
This will cause the JVM to load one more class when it starts, which can be seen as follows
public class Startup {
public static void main(String[] args) {}
}
java -verbose:class Startup
[0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base
There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit.
In addition, the existing accessor methods on HexFormat already return boolean, and a few incoming parameters are called `ucase`. Thus, we propose to change the representation with a boolean field called `ucase`, which increases the consistency across HexFormat API and implementation.
class HexFormat {
private enum Case {
LOWERCASE,
UPPERCASE
}
}
This will cause the JVM to load one more class when it starts, which can be seen as follows
public class Startup {
public static void main(String[] args) {}
}
java -verbose:class Startup
[0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base
There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit.
In addition, the existing accessor methods on HexFormat already return boolean, and a few incoming parameters are called `ucase`. Thus, we propose to change the representation with a boolean field called `ucase`, which increases the consistency across HexFormat API and implementation.
- links to
-
Commit(master) openjdk/jdk/84c74ad0
-
Review(master) openjdk/jdk/20060