On Wed, 5 Aug 2026 15:59:05 GMT, Nir Lisker <[email protected]> wrote:

> > Once you've resolved that, update the CSR
>
> Is there still a CSR update needed?

Yes. The CSR was last updated in December. At least the following changes are 
needed:

1. Check the "Behavioral" box in the "Compatibility Kind" section to indicate a 
(minor) behavioral compatibility risk. Add a brief note that each affected 
converter instance now caches its computed NumberFormat or legacy DateFormat 
rather than recreating it for each conversion. Applications are unlikely to be 
affected.
2. Attach a spec diff, such as the output of "git diff" (for the files that 
affect the public javadoc) or the apidiff tool.
3. In the Specification section, in the list of removed methods, 
`CurrencyStringConverter.getNumberFormat()` was formerly protected, not public 
(so should be split from `PercentageStringConverter.getNumberFormat()`)
4. In the Problem and Solution sections, add a note about the caching of the 
format in some of the converter subclasses.
5. In the Specification section, add something about the possible behavioral 
changes relating to caching of format instances in `NumberStringConverter` and 
`DateTimeStringConverter`.


I also noticed three changes related to exception processing.

* In the java.time converters, an all-whitespace string is trimmed before the 
empty string check, which means that such a string will now return `null` 
rather than being passed to the parser, producing a parsing error.
* A null format passed to `FormatStringConverter(Format)` will cause an NPE at 
construction time rather than later when used
* An IllegalArgumentException is now thrown instead of a generic 
RuntimeException when bad data is passed that causes a parsing error.

The first seems good to me. The new behavior matches what we do in other cases 
(and is more along the lines of a bug fix anyway).
The second is also good, and the updated docs say "must not be null", so this 
will show up in the spec changes.
The third is a compatible change (IAE is a subclass of RuntimeException), but 
points out a preexisting problem in that we don't document any exceptions at 
all, so I recommend filing a follow-up bug to add the missing @throws tags to 
the docs.

I think none of these three items need to be separately mentioned in the CSR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1880#issuecomment-5207825727

Reply via email to