RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format
Roger.Riggs at oracle.com
Mon Mar 9 14:01:02 UTC 2020
Updating the spec to match the implementation is a good idea.
Whether adding a new method is worthwhile depends on whether *any*
UUID has been actually been seen. Humans don't type UUID's so if there
ones out there, they have been generated by some other framework or library.
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 about breaking existing
>> 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
>> 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
>> 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.
More information about the core-libs-dev