Changing observed property value in EventHandler changes Event properties - kotlin

Question

I have a TableView with a column of ComboBox cells, created with ComboBoxTableCell.forTableColumn(). I'm very new to JavaFX. You may want to skip to "TLDR" at the bottom before going through all of it.
In onEditCommit() for the column, I launch an Alert to get confirmation ("Really ____?"). If it isn't confirmed, I want the cell's value to revert to what it was originally. The observed property is a SimpleStringProperty, and the table/row/bean type is a FooBar object. The table is backed by an ObservableList<FooBar>, retrieved using the Event object. This is the EventHandler, in kotlin:
EventHandler { ev ->
ev.newValue?.let { str ->
println("A old ${ev.oldValue} ===> new ${ev.newValue}")
list[ev.tablePosition.row]?.let { foobar ->
if (str != foobar.prop.value) {
val confirm = runDialog()
if (!confirm) foobar.prop.value = ev.oldValue
println("B old ${ev.oldValue} ---> new ${ev.newValue} "
+"| prop ${foobar.prop.value}")
}
}
}
}
The ComboBox has three options, "Alpha", "Beta", "Charlie". Here's what happens when I select the ComboBox and change the value, but then cancel in the confirm dialoge (the actual output is indented):
[ Box reads "Alpha"; select "Beta" ]
A old Alpha ===> new Beta
[ Cancel dialog... Box reads "Beta"
B old Alpha ---> new Beta | prop Alpha
[ Repeat by selecting "Charlie" ]
A old Alpha ===> new Charlie
[ Cancel dialog ]
B old Alpha ---> new Charlie | prop Alpha
[ Box reads "Charlie" ]
Notice that the property is being reset, but the cell contents aren't reflecting that. I thought this might be an issue with what happens when the handler returns -- ie., the commit happens afterward -- but using Platform.runLater() to set the property did not make a difference.
What did is intuiting that the edit is never committed, ie., foobar.prop.value is always the same, so setting it to oldValue doesn't change anything. However, the ComboBox is still out-of-sync with the property it is supposed to be an observer of.
This theory is supported by the fix, which is to stash oldValue and set foobar.prop to something new before running the dialog.
val orig = ev.oldValue
list[ev.tablePosition.row]?.let { foobar ->
if (str != foobar.format.value) {
// Set before dialog.
foobar.format.value = ev.newValue
val confirm = runDialog()
if (!confirm()) foobar.format.value = orig
But what's a bit mysterious here is why orig is necessary at all -- why not just foobar.format.value = ev.oldValue? Because ev.oldValue changes in between the third
last and last lines above; I'm guessing the Event object is actually being recycled and set with foobar.format.value. Or it could have to do with the dialog, which probably makes it a bone fide bug. Here's what happens using the fix:
[ Box reads "Alpha"; select "Beta" ]
A old Alpha ===> new Beta
[ Cancel dialog... Box reads "Alpha"
B old Alpha ---> new Beta | prop Alpha ]
So I am at least able to get what I want, but I am troubled by all this unexpected behaviour.
Here's what happens if, instead of using orig, I change that assignment to ev.oldValue (with no other changes):
[ Box reads "Alpha"; select "Beta" ]
A old Alpha ===> new Beta
[ Cancel dialog... Box reads "Beta" ]
B old Beta ---> new Beta | prop Beta
Back to the same problem.
(TLDR) This means changing foobar.prop.value in the handler has the side affect of changing ev.oldValue.
Confirmed with:
println("old ${ev.oldValue}")
foobar.prop.value = ev.newValue
println("old now ${ev.oldValue}")
Which I guess is the short version of this question. I'm sure I'm not the first to notice this. Is that behaviour expected, documented or easily explicable? I suppose there is a certain desirability in it, but it makes the Event object seem a bit shifty.
There's also the matter of the ComboBox falling out of sync with the value, which does not seem desirable at all.
This is openjfx 11 on x64 linux.