RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4 [v36]

[Phil Race]

On Thu, 17 Aug 2023 23:13:51 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 51 commits:
> 
>  - Merge scientificware-patch-003-CSS-add_4_8_digits_hex_coded_color
>    
>    # Conflicts:
>    #	src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>  - Merge master
>  - Merge branch 'master'
>    
>    CSS.java :
>    Removes assigning values inside the if-condition
>    Extracts the assignments into separate line.
>    
>    Hex3468DigitsColor.java :
>    Adds a message to result in case of failure only
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Update imports
>    
>    Remove java.util.Pattern and add java.util.Map imports
>  - Performance improvement
>    
>    Performance results came from my repository I mentioned in the header.
>    
>        The code before this PR ran in 230ms.
>        Our previous codes ran in 1 200ms to 1800 ms with String + formatted + %n$s usage.
>        They ran in 350ms to 380ms with String + formatted + %s usage.
>        And in 100ms to 110ms if we replace String + format with a string concatenation.
>        Now the code below gives the same results in 36ms and with all our expected behaviors. Since we control notation length we
>            can bypass some controls,
>            directly generate the color value,
>            without generate a new string,
>            and reject a wrong number format without generate any exception.
>  - Corrects a value in a message.
>    
>    A message is added to the result in case of failure only. The updated code does not output the actual value. The tested color is #f12a instead of #f00a.
>  - Simplifications of the test.
>    
>    Removes individual color tests and only compares the RGB value.
>  - Renames an identifier.
>    
>    Suggested change, not to use `l` as an identifier because it could be confused with `1`.
>    This part of code could change and be replaced by bits right rotation after  performance tests.
>  - ... and 41 more: https://git.openjdk.org/jdk/compare/a8ab3be3...6a6af622

Sorry, slow in getting back to this. I ran out test suite against this change.
The only problem was that a TCK test failed. It is a negative test which was checking that only the color strings specified to be supported worked. That test will be updated by the TCK team as a result of the CSR which we need to file anyway.
I'll create the CSR for you and populate it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9825#issuecomment-1751349203