RFR: 8251989: Hex formatting and parsing utility [v2]

[Roger Riggs]

On Wed, 14 Oct 2020 09:28:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>>   qualifications, etc.
>
> src/java.base/share/classes/java/util/HexFormat.java line 41:
> 
>> 39:  * formatting markup such as prefixes, suffixes, and delimiters.
>> 40:  * <p>
>> 41:  * There are two {@code HexFormat}ters with preset parameters {@link #of()} and
> 
> Just a nit comment: stylistically, mixing fixed fonts and variable length fonts in a single word does not always
> display well. Alternative include using plain words, and use {@linkplain } to link to the class/method described (e.g.
> `{@linkplain HexFormat hexadecimal formatters}`), or reword (e.g. `There are two factories returning instances of
> {@code HexFormat} with ...`)...

Agreed, will fix.  I don't use @link to link to the javadoc of the class the link appears in.  A link to self is
misleading and distracting.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1116:
> 
>> 1114:         }
>> 1115:
>> 1116:         HexFormat format = HexFormat.of().withUpperCase();
> 
> Should/can this be a static final field in the class?

Its a bit of a space/time trade-off.  And the balance point will change if the class is converted in the future to a
Valhalla primitive class. At this point it looks to me like a premature optimization.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482