Hi,
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
