JDK-8165199: UUID.fromString(str) compliance checking?
Roger.Riggs at oracle.com
Mon Dec 17 14:47:01 UTC 2018
I could imagine a more performant implementation as Claes suggested by
expecting the format and
only those characters defined by the rfc 4122. And it could retain
compatibility by faulting back to
the current implementation for other formats and characters outside of
those in the rfc.
But it would only be worthwhile if the performance improvement was
significant and worth
having two copies of the code.
On 12/15/2018 01:22 PM, Joe Darcy wrote:
> On 12/14/2018 2:00 PM, Andrew Leonard wrote:
>> Yes, this was my concern, source compatibility...
>> With the current implementation it is not too harmful to "sloppy" app
>> code. If it's not causing any other underlying "bug" then I would be
>> tempted to leave this "sleeping dog..."
> To use language precisely, the kind of compatibly at issue here is
> *behavioral* compatibility. From the definitions used by in the CSR
> "For Java programs, there are three main categories of compatibility:
> Source: Source compatibility concerns translating Java source code
> into class files.
> Binary: Binary compatibility is defined in The Java Language
> Specification as preserving the ability to link without error.
> Behavioral: Behavioral compatibility includes the semantics of the
> code that is executed at runtime."
> Since the proposed change would only impact the implementation and not
> the method signatures, etc. it is a behavioral compatibility concern.
> Given the length of time the existing behavior has been present, I
> would be hesitant to change it now.
More information about the core-libs-dev