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