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