RFR: 8251989: Hex formatting and parsing utility
Roger Riggs
rriggs at openjdk.java.net
Fri Oct 2 20:38:38 UTC 2020
On Fri, 2 Oct 2020 19:14:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:
> The class name already has `Hex` inside, and methods names still contain it. Also, I found it unexpected that
> `fromHexDigits` returns an integer. Can we use `encode`, `decode`, `decodeInt`, `decodeLong` etc?
Including 'Hex' in the method names reinforces the function, without it, more context is required to make the code
readable.
The decoding of hexadecimal digits to a binary number is at its core untyped and unsigned for all three fromHexDigits
methods. A signed type such as byte does implicit sign extension and in many use cases it would need to be masked
before the value is used. An explicit cast in the source to a smaller primitive makes the use clearer explicit.
The formatHex and parseHex methods operating on byte arrays are quite different than toHexDigits and fromHexDigits.
When operating on byte arrays, the prefix, suffix, and delimiter are included in the conversion.
The toHexDigits and fromHexDigits methods do not include prefix and suffix, and delimiter and just convert.
The different naming helps create a clear distinction. Also it was mentioned in comments on the first version of the
API, that encode and decode can be ambiguous as to which direction the conversion is going.
-------------
PR: https://git.openjdk.java.net/jdk/pull/482
More information about the core-libs-dev
mailing list