RFR: 8251989: Hex formatting and parsing utility

[Roger Riggs]

On 10/12/20 7:08 PM, Marcono1234 wrote:
> src/java.base/share/classes/java/util/HexFormat.java line 836:
>
>> 834:      *          otherwise {@code false}
>> 835:      */
>> 836:     public boolean isHexDigit(int ch) {
> Should this method be `static`? Or otherwise should it consider the `uppercase()` setting?
> (Same for `fromHexDigit` and all the other subsequent methods)
>
> These methods being instance methods is likely pretty confusing because they are unrelated to the HexFormat instance
> and makes using them cumbersome because the user has to create a HexFormat instance first.
All of the functions that convert binary to strings are formatting, 
though a simpler term could be used.

As for static vs instance methods, there are a number of competing 
interests.

  - Asymmetry between toHex and fromHex methods if the former were 
instance and the later were static methods.
  - The HexFormat context is needed for the prefix, suffix, and 
delimiter for the byte array versions vs the primitive value versions.
  - If the fromHex methods are static, and the toHex methods remain 
instance methods due to the uppercase/lowercase paramter, that's another 
kind of asymmetry.
  - Invoking and imports for static methods pushes the code to take on a 
different shape that is less appealing when mixed. (IMHO)

As the design was maturing, the choice was to keep all of the methods 
related to the parameters via the HexFormat instance.
Though there are no forseen future enhancments, keeping all the methods 
as instance methods would allow possible extensions to consistently 
apply to all formatting and parsing methods.

Are there other considerations that should be taken into account?

Regards, Roger