On Wed, 23 Jul 2025 19:44:44 GMT, Alexey Ivanov <[email protected]> wrote:
>I think the specification for the index parameter — “an index within the text” >— is vague, it's open to interpretation. >We should make it specific. For example, is 0 within the text? It's not >within, it's right before. I'm not sure I agree with this argument. The indexes mentioned in all these specs are character indexes. Index 0 refers to the first character in the text, and the last valid index is length - 1. I think some confusion arises from misinterpreting the "index within the text" in the spec and the caret position returned by getCaretPosition. As specified, the caret position is “the zero-based offset of the caret” and it is located between characters. So this value cannot be used directly as a character index in other methods. > I said it a few times now, “an index within the text” is a vague condition, > we should update the specification so that it is clear which indexes are > valid. The phrase “an index within the text” appears around 30 times in the spec, and all the relevant methods are implemented consistently to support the index range [0, length - 1]. We could clarify the wording, but why change it to allow character positions outside the text? >I agree with @azuev-java here, we should focus on the purpose of the API and >how this API is supposed to be used. The proposed change would make all existing subclasses, including custom ones, non-compliant with the spec. For example, our own JPasswordField would no longer behave as specified. What exactly are we trying to fix here? What is the issue that cannot be addressed by using the correct methods for the first or last character positions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3181607843
