RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText() [v2]

[Prasanta Sadhukhan]

On Wed, 26 Jul 2023 03:27:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. 
>> Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself.
>> Fix is made to treat setText as in edit mode and commit the changes made to it.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setDocument and test fix

> > I wonder what happens if `setText` is called with a value that cannot be interpreted by the current formatter and how it plays with different policies on focus lost as outlined in [the javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFormattedTextField.html).
> 
> ~It should be safe because `commitEdit` is guarded by `isEditValid`.~
> 
> I was about to write the above but I looked deeper in the code, and my opinion has changed dramatically.
> 
> Let's see what's happening when `setText` is called. The first thing that's done is `super.setText` is called. So far, so good.
> 
> The call `super.setText` mutates the text model, `Document`; as the result, the `edited` flag is set to `true` by `DocumentHandler` and its `insertUpdate` and/or `removeUpdate` methods.
> 
> When is the text validated? When is `isEditValid` set to `true` or `false`? The comment for the `setEditValid` method says, “This will invoked by `AbstractFormatter` as the user edits the value.” I can't see where and when `AbstractFormatter` gets called in this case.
> 
> Things aren't as clear now…
> 
> The documentation for [`JFormattedTextField`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFormattedTextField.html#) suggests the `setValue` method should be used to set the value.
> 
> When you edit the value, the `setText` method is used to change the displayed text as the `JFormattedTextField` switches into editing mode and back. As such, changing the implementation of `setText` (and `setDocument`) adds an overhead.
> 
> It looks as if `setText` and `setDocument` as well as methods of `Document` may mutate the text bypassing the formatter, thus breaking the invariants provided by the `JFormattedTextField` class. Perhaps, if it were possible, the direct access to `setText`, `setDocument` and `getDocument` should be restricted.
> 
> Taking into account everything I said above, I strongly believe the fix is not necessary and the bug should be closed as either _Not an Issue_ or _Won't Fix_.
> 
> **The correct fix** to the sample provided is to _use the `setValue` method instead of `setText`_.
> 
> In `JFormattedTextProblem.java`, replace the lines
> 
> ```java
>     dateField.setText(displayDate.format(new Date()));
>     timeField.setText(displayTime.format(new Date()));
> ```
> 
> with
> 
> ```java
>     dateField.setValue(new Date());
>     timeField.setValue(new Date());
> ```
> 
> and both formatted text fields, `dateField` and `timeField`, behave as expected.

I tend to agree..Besides the fix is also causing couple of JCK test to fail as setText->commitEdit->setValue->setFormatter->format.install->setText causing StackOverflowError
so seems like setValue, as you told, should be used instead..

Closing this as Not an Issue

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

PR Comment: https://git.openjdk.org/jdk/pull/14993#issuecomment-1698515659