Source code of javafx.scene.control.TextInputControl.TextProperty#doSet of "javafx-controls-21-win.jar"

[Oliver Kopp]

Hi,

Ah, nice. I see.

OK, then the issue for the NPE is deeper in the setting of "undoChange".

In short:

        TextField textField = new TextField();
        textField.setPromptText("Type something and then press Ctrl+Z.");
        vbox.getChildren().add(textField);
        SimpleStringProperty textProperty = new SimpleStringProperty();
        textProperty.addListener((_, _, newValue) ->
textField.textProperty().set(newValue));
        textField.textProperty().addListener((_, _, newValue) ->
textProperty.set(newValue));

When typing something and then presses Ctrl+Z, the exception is:

Exception in thread "JavaFX Application Thread"
java.lang.NullPointerException: Cannot read field "next" because
"this.undoChange" is null
        at javafx.controls at 22.0.1
/javafx.scene.control.TextInputControl.updateUndoRedoState(TextInputControl.java:1250)
        at javafx.controls at 22.0.1
/javafx.scene.control.TextInputControl.undo(TextInputControl.java:1201)
        at javafx.controls at 22.0.1
/com.sun.javafx.scene.control.behavior.TextInputControlBehavior.undo(TextInputControlBehavior.java:553)

I know that this minimal example is not a good code. a two-way bindings
should be used there. However, we need this to re-position the cursor right
if another thread modifies the text content. If we do not modify the cursor
position, the cursor jumps to position 0. Our use case is to "reformat on
save". This is also a feature of IntelliJ. For instance, imports are
organized. If IntelliJ modifies the Java file, the cursor keeps its
position relative in the text and does not move to the first column in the
first line.

(Full example for compilation at
https://github.com/Siedlerchr/javafxreproducer/pull/22)

Cheers,

Oliver

Am So., 7. Juli 2024 um 13:28 Uhr schrieb Johannes Riecken <
johannes.riecken at gmail.com>:

> Hey Oliver
>
> The Java compiler does in fact do some "smart" optimizations, which you
> can easily verify by writing a void function with an early return yourself,
> compiling it to a class file and decompiling the class file again :) In
> this case, I assume that having a single point of exit helps the compiler
> to analyze control flow.
>
> Cheers
>
> Johannes
>
> On Sun, Jul 7, 2024 at 9:45 AM Oliver Kopp <kopp.dev at gmail.com> wrote:
>
>> Dear all,
>>
>> I have a strange thing here in JavaFX - and I seek some guidance, what to
>> do.
>>
>> I am searching for the source code of
>> javafx.scene.control.TextInputControl.TextProperty#doSet of
>> "javafx-controls-21-win.jar".
>>
>> Using a decompiler, the method reads as follows (shortended):
>>
>>
>> private void doSet(String var1) {
>> ...
>>     if (TextInputControl.this.filterAndSet(var1)) {
>> ...
>>         TextInputControl.this.textUpdated();
>>         TextInputControl.this.resetUndoRedoState();
>>     }
>> }
>>
>>
>> I checked the source on GitHub at
>> https://github.com/openjdk/jfx/blob/72701e6cb4095b8f5042f54ae6bb2c0cec446bcf/modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java#L1511
>> :
>>
>>
>> private void doSet(String value) {
>> ...
>> if (!filterAndSet(value)) return;
>> ...
>> textUpdated();
>> ...
>> resetUndoRedoState();
>> }
>>
>>
>> I assume that the Java compiler does not do some "smart" optimizations.
>> Thus, the binary is different from the source somehow.
>>
>>
>> Can someone explain me what is happening here? Why is the decompiled
>> source different from the Java source?
>>
>>
>> TYIA and cheers,
>>
>> Oliver
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-discuss/attachments/20240707/e2ffe01e/attachment-0001.htm>