ListProperty and ListBinding

[Gaja Sutra]

> public interface ObservableListValue<E>  extends ObservableObjectValue<ObservableList<E>>, ObservableList<E>  {}
> public interface WritableListValue<E>  extends WritableObjectValue<ObservableList<E>>, ObservableList<E>  {}
>
> Notice that this is different than all other ObservableValues and WritableValues, that we have so far, because ObservableListValue and WritableListValue also extend ObservableList.
Very clean and integrated design. I like it, even if I have a small 
question.
Will ObservableListValue.{add|remove}Listener(InvalidationListener) 
[coming from Observable interface] be processed following contract of 
ObservableObjectValue<ObservableList<E>> [change of list in this 
ObservableListValue<E>] or following contract of ObservableList<E> 
[change in contents of the list in ObservableListValue]?
A possibility would be choose the first case, but add another 
subinterface of InvalidationListener for allowing access to the other case:
|public interface ListInvalidationListener extends InvalidationListener {
     //  notified in second case.
     public void invalidatedContent(ObservableListValue);
}|

> A content binding means, that the values are copied from one list to another. This way a read only property like Group.children can be bound to other lists.
I think a final modifier on Group.getChildren() will possibly be useful, 
if user can not provide an externally managed list even by subclassing 
Group (it is suggested for TreeItem.getChildren()).
Content binding will be very useful for some future UI components 
needing more than a listener on a list coming from anywhere: by example 
a RichTextArea will have, for each paragraph, a list of styled inlines 
like styled text, but will need to display a different text, because it 
will manage and add hyphens and line-breaks. It will probably have an 
internal more complex representation and expose paragraph as an list 
(editable view of its internal enhanced representation), with a 
non-externally manageable initialization (it's a view, not a real list). 
Binding it simply to the view of a model in the back-end of application 
or some other non-manageable model of UI component (like WebView) will 
be good and will be largely simpler with content binding of lists.

> [...]     public static void unbindContentBidirectional(Object obj1, 
> Object obj2) {...}
Static methods added to Bindings does not specify in their name the 
(Observable)List target of content binding (unlike some name like 
"(un)bind*List*ContentBidirectional").
Will it be a problem, given than List is an interface and a specific 
class can implement multiple interfaces, then multiple types of 
bindings? [it's only a question].
I currently don't find any realistic use-case, but supposing we have two 
objects, each implementing List and Map, and we want to bind/unbind 
together only as List or as Map, we can have a problem with current names.
Preceding ObservableListValue is an example of an object having two 
Observable natures (ObservableObjectValue and ObservableList). Another 
example can be a SVGPath being a String and a Shape: binding together 
two paths can be made at String or at Shape level.

> Any thoughts?
Very interesting. I'm really happy to see these two features.