A common reason for using the `TextFormatter` is the need for a `filter`.
Therefore, the following constructor is typically used:
`public TextFormatter(@NamedArg("filter") UnaryOperator<Change> filter) { ... }`With that, no `valueConverter` is set in the `TextFormatter`. When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is called. Since `valueConverter` is null, an NPE is thrown and catched inside it and `TextFormatter.updateText()` is called (which will call `TextInputControl.updateText(...)`), which won't do anything either since `valueConverter` is still not set (=null). A minor improvement here is to just skip `TextFormatter.updateValue(...)` and therefore `TextFormatter.updateText()`, since this methods won't do anything without a `valueConverter`. With that change, no exception is thrown and catched, and therefore also exception breakpoints are not called. This will also slightly increase the performance, as throwing exceptions is a (minor) bottleneck. ------------- Commit messages: - 8286552: TextFormatter.updateValue(...) won't call updateText(), when no valueConverter is set Changes: https://git.openjdk.java.net/jfx/pull/794/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=794&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286552 Stats: 79 lines in 2 files changed: 75 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/794.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/794/head:pull/794 PR: https://git.openjdk.java.net/jfx/pull/794
