RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format

Roger Riggs Roger.Riggs at oracle.com
Mon Mar 9 14:01:02 UTC 2020


Hi,

Updating the spec to match the implementation is a good idea.

Whether adding a new method is worthwhile depends on whether *any* 
non-conforming
UUID has been actually been seen.  Humans don't type UUID's so if there 
are non-conforming
ones out there, they have been generated by some other framework or library.

Thanks, Roger


On 3/8/20 9:53 AM, Alan Bateman wrote:
> On 06/03/2020 18:15, Roger Riggs wrote:
>> Hi Chihiro, et.al.,
>>
>> Thanks for taking a look at this issue,  however...
>>
>> There has been a long history of concerns[1] about breaking existing 
>> applications
>> that depend on the loose parsing of UUIDs.  Throwing an exception 
>> where it did not
>> previously is an incompatible change.
>>
>> The crucial concern about performance parsing conforming strings has 
>> been addressed by:
>>
>> 8196334 Optimize UUID#fromString 
>> <https://bugs.openjdk.java.net/browse/JDK-8196334>
>>
>> I propose to close these as WILL-NOT-FIX: and hope that the next 
>> several times it gets reported
>> they will be closed as duplicates.
>>
>> 8216407 <https://bugs.openjdk.java.net/browse/JDK-8216407> 
>> java.util.UUID.fromString accepts input that does not match expected 
>> format
>>
>> 8165199 
>> <https://bugs.openjdk.java.net/browse/JDK-8165199>UUID.fromString 
>> accepts wrong placements of the dashes
> As you say, any tightening up of the validation after 15+ years will 
> create a potential compatibility issue and might not be worth it. 
> Maybe we could re-purpose JDK-8216407 to clarifying the javadoc 
> instead? That would at least help with these bug reports when people 
> are surprise that fromString doesn't fail.
>
> -Alan



More information about the core-libs-dev mailing list