JDK-8165199: UUID.fromString(str) compliance checking?

Roger Riggs 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.

$.02, Roger

On 12/15/2018 01:22 PM, Joe Darcy wrote:
> Hello,
> 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 
> process:
> "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."
> https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility
> 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.
> HTH,
> -Joe

More information about the core-libs-dev mailing list