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. I'd prefer the latter, since some implementation might want to strictly follow the RFC2616 spec. So we can say the JDK's implementation allows more than three fraction digits, or scientific notations as an `@implNote`. btw, I wrote: I don't think a spec update is needed for -0.0. Since MIN_WEIGHT is 0.0, -0.0 compares equal to the inclusive lower bound and does not satisfy weight < MIN_WEIGHT, so it remains accepted Not RFC 2616, which is now obsolete, but the latest RFC 9110 reads: The weight is normalized to a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means "not acceptable". If no "q" parameter is present, the default weight is 1. So the value of 0 is "not acceptable" in their terminology 🙂 ------------- PR Comment: https://git.openjdk.org/jdk/pull/31697#issuecomment-4814021752
