On Tue, 11 Jan 2022 17:21:13 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
> The question is whether or not `null` should be a valid value for the > `selectionModel` and `focusModel` properties. I think there are good reasons > to think that it shouldn't. The primitive property classes > (`IntegerProperty`, `BooleanProperty`, etc.) have the same issue, and they > deal with this situation by coercing the invalid `null` value to their > respective default value. I think the property classes for primitives are another use case, since those values really can't be null. I get your point but I think a null `selectionModel` or `focusModel` should be allowed. At least an use case would be to have a read-only `ListView` which should not be selectable nor focusable. If you just set a ListView to uneditable (via `setEditable(..)`), you can still select entries. If you disable the `ListView` it is grey styled which is not desired in this use case. Of course I can change the style, but a null selection and-focusModel may make sense as well. But I agree to a certain point, maybe it make's sense to fail for some properties when null is set/or use default values (but without changing the property?). Right now some properties in e.g. `Node` can be set to null and it will throw a NPE somewhere (e.g. `setCacheHint(null)`, `setRotationAxis(null)`, `Labeled.setFont(null)` ...). But on the other hand a lot of code handle properties with null with some kind of default behaviour (the property itself is never changed). Examples for this: - `Labeled.getTextOverrun()` -> null will be handled as ELLIPSIS in LabeledSkinBase - `Labeled.getEllipsisString()` -> null will be handled as "" in LabeledSkinBase - ... So there is no consistent behaviour for this, but a lot of code already handles null by behaving in some kind of default way without changing the property directly, and I think it might be the best to adapt to this. ------------- PR: https://git.openjdk.java.net/jfx/pull/711
