Comment on CSR 8251991: Hex formatting and parsing utility

[Raffaello Giulietti]

Hello,

I understand your points expressed in 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html

On the other hand, it kind of hurts when the javadoc spec implies that 
the fromXXX() methods do not logically depend on the state and yet one 
has to invoke them on some instance anyway.


As for HexFormat.of() to always return the same instance, you are of 
course right in observing that this is out of place for value-based 
classes. The intent was to describe a static-like idiom that would deter 
programmers to rewrite their own static version of these methods.


Greetings
Raffaello


> Hi,
> 
> The question about static vs instance methods was raised during the review.
> At the time, my rationale for the current API is summarized in this email.
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html
> 
> It comes down to choosing one kind of consistency vs another.
> 
> I was/am looking for additional comments to weigh one or the other 
> alternative.
> I did receive one offline comment in support of static methods on the 
> rationale of
> convenience.
> 
> Regards, Roger
> 
> 
> On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
>> Hi,
>>
>> the javadoc of most of the methods listed in my previous post below 
>> reads:
>>     "The delimiter, prefix, suffix, and uppercase parameters are not 
>> used."
>>
>> As these eventually constitute the whole state of an instance of this 
>> final class and as the state is not involved, it is possible to 
>> declare the methods as static.
>>
>>
>> If, for some reason, declaring the methods as static is not a choice, 
>> the next best thing is to clarify that
>> * HexFormat.of() always returns the same instance and thus
>> * absent any other instance, the recommended idiom for invoking any of 
>> the methods below is, for example,
>>     HexFormat.of().isHexDigit('F')
>> (because there are almost no additional costs wrt static methods.)
> Note that HexFormat is specified as a value based class and
> any statement related to identity is out of place.
> 
> Incidentally, its generally discouraged and can cause a warning when a 
> static method is invoked using a reference.
> 
>>
>> But I don't see a reason why they should be non-static. Just oversight?
>>
>>
>> Greetings
>> Raffaello
>>
>>
>> On 2021-03-08 11:52, Raffaello Giulietti wrote:
>>> Hello,
>>>
>>> it appears that all of the following API methods in [1] can be 
>>> declared *static*, which makes them more useful in contexts where 
>>> there's no instance of HexFormat available or none is desired.
>>>
>>> As 17 has not yet entered any formal phase, the change should be 
>>> harmless.
>>>
>>>    public boolean isHexDigit(int);
>>>    public int fromHexDigit(int);
>>>    public int fromHexDigits(java.lang.CharSequence);
>>>    public int fromHexDigits(java.lang.CharSequence, int, int);
>>>    public long fromHexDigitsToLong(java.lang.CharSequence);
>>>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>>>
>>> Greetings
>>> Raffaello
>>>
>>> ----
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991