On Tue, 10 Feb 2026 02:25:48 GMT, Michael Strauß <[email protected]> wrote:
>> I added a test that should clarify the handling for mismatched types. The >> test passes both in the old and new implementation to show that the >> behaviour is the same and in both cases, null is never returned on >> mismatched types > > This is not an equivalent change: Before the change, a `ClassCastException` > could have been thrown from `observable.getValue()`, which is then swallowed > and logged. After the change, the exception bubbles up to the caller. > > However, the old code doesn't make any sense at all, because it doesn't do > what the original author intended it to do. Christopher is correct: the > generic type `T` doesn't have a lower bound, so it is erased to `Object` in > the method descriptor: `()[Ljava/lang/Object;`. The statement `return > (T)observable.getValue();` can therefore never throw a `ClassCastException` > at runtime, because any reference type is convertible to `Object`. The > try-catch block is dead code at best, and actually _hides_ an unrelated > `ClassCastException` that was thrown from `observable.getValue()`; it > confusingly logs that the "select-binding has wrong type", which is not what > has happened. Alright, so it is technically not an equivalent change, but only because the old implementation was wrong. However, I assume that any getValue() call should not throw any classcastexception if it is properly implemented. So the likelyhood of any consequences of this change are very minor and can only happen for like custom implementations that throw a classcastexception. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2934512150
