On Fri, 26 Jun 2026 20:33:27 GMT, Justin Lu <[email protected]> wrote:
>> This PR addresses an edge case where the `Locale.LanguageRange(String, >> double)` constructor accepts `Double.NaN` as a weight. A `LanguageRange` >> weight is specified by >> https://datatracker.ietf.org/doc/html/rfc2616#section-3.9 and must be >> between 0.0 and 1.0, inclusive. The existing bounds checks do not handle >> this case. This change adds an explicit `Double.isNaN(weight)` check. >> >> The issue does not affect parsed range strings in the same way, since the >> input is normalized to lower case before parsing and `"nan"` is not accepted >> by `Double.parseDouble`. However, I added a test for that case as well, >> since one did not previously exist. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > Review - Add spec update to throws clause Yes, for the constructor, I believe we are covered on the -0.0 case with the current throws wording. What is more questionable are the `parse` methods that accept the weight within the range string. These methods are specified to throw if the weight is not a RFC 2616 qvalue, > qvalue = ( "0" [ "." 0*3DIGIT ] ) > | ( "1" [ "." 0*3("0") ] ) > However, since the implementation relies on `Double.parseDouble`, values such as the `-0.0` case as well as `+0.0`, `0.0e0`, and `0.0000` are all technically not valid qvalues, yet are accepted. I don't think there is much benefit in adding validation on the weights to match that exact syntax structure. We may need to soften the specification’s reliance on RFC 2616, perhaps by defining accepted weights in terms of the RFC 2616 minimum and maximum quality weight boundaries, rather than saying they exactly match RFC 2616 quality values. We could also take a different approach and clarify via an `@implNote` that this implementation is more lenient as it uses `Double.parseDouble`. I am not sure if either of you would have a preference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31697#issuecomment-4813892095
