> Yes, one of the features the new design provides is ability to modify key > mappings by the user at runtime. So yes, not only it needs to be mutable, > but it also adds some APIs for exactly that. >
I struggle to see a use case for this feature. I can imagine that there might be some use cases that call for customized input mappings, but why would this translate to a _mutable_ input map? That's quite a departure from the way other parts of JavaFX work. For example, skins are also immutable. If you want to have a different skin for a control, you don't somehow modify the existing skin instance; instead, you'd create a new skin class (or -- somehow -- extend an existing skin class), and then install that new skin on your control. An input map shouldn't bind input events directly to instance methods of a particular control instance. It should define the mapping of events to methods symbolically: Instead of mapping Event => instance.method(), it should map Event => Control::method. The input map could then be stateless and immutable, and can be set on any control instance. If you want to change the mappings, just set a different input map instance. There's no need that an input map would retain a reference to any particular control, since the control reference can be passed into the input map just as easily.
