JDK-8165199: UUID.fromString(str) compliance checking?

joe darcy joe.darcy at oracle.com
Fri Dec 14 16:58:03 UTC 2018


Hello,

Note that a fix to this issue would require a CSR 
(https://wiki.openjdk.java.net/display/csr/Main) to either assess the 
behavioral compatibility impact of changing the existing behavior or to 
review a new API added for stricter parsing.

Cheers,

-Joe

On 12/14/2018 8:42 AM, Claes Redestad wrote:
> Hi,
>
> a stricter implementation could also be (much) more performant. I've
> been meaning to propose a patch that makes strict mode default and adds
> a configuration option to fall back to the current, relaxed
> implementation. Adding such compatibility options always feel a bit like
> a dirty hack, though.
>
> /Claes
>
> On 2018-12-14 17:24, Andrew Leonard wrote:
>> hi,
>> So i'm just taking a look at what appears quite a simple bug :
>> https://bugs.openjdk.java.net/browse/JDK-8165199 , at least the fix is
>> simple to make UUID.fromString(str) strictly uuid bnf compliant. 
>> However,
>> I wanted to get community opinion on potential "compliance" issues with
>> doing such a fix?
>> As it currently stands the method will allow any string up to 36
>> characters containing 4 "-"'s, eg: this would be valid
>>      abc-123-123-123-abc123
>> whereas a properly formatted UUID string should be hex values of lengths
>> 8-4-4-4-12.
>>
>> There are obvious implications in increasing the validation that it 
>> could
>> break some existing applications that were either knowing or 
>> un-knowingly
>> specifying the strings in a non-spec way...
>>
>> am I just being paranoid..!? Thoughts?
>>
>> Thanks
>> Andrew
>>
>> Andrew Leonard
>> Java Runtimes Development
>> IBM Hursley
>> IBM United Kingdom Ltd
>> Phone internal: 245913, external: 01962 815913
>> internet email: andrew_m_leonard at uk.ibm.com
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>> PO6 3AU
>>


More information about the core-libs-dev mailing list