I'm not involved in the development of the binding API, so I'll leave a
full response to the professionals, but you may be interested in this
jira that was just resolved yesterday by Martin:
https://javafx-jira.kenai.com/browse/RT-31031
-- Jonathan
On 14/06/2013 11:41 a.m., John Hendrikx wrote:
Hi List,
I'm having a hard time to find good documentation on some aspects of
bind and bindDirectional. I found several forum posts, some books and
lots of examples, but none really touch upon the subject of references
between bindings and garbage collection.
Would it be possible to enhance the javadocs a bit or create a
tutorial for this? Things that are unclear for me (until I test by
trail and error), so correct me if I got something wrong:
1) Garbage collection of bindings; basically, X.bind(Y) will result in
X's lifecycle to be bound to Y. If Y is a long-lived object, and X is
a short-lived frequently replaced object, then many instances of X
will be left around consuming memory (and CPU cycles on every Y
update) until Y dies. A single forgotten binding of this type can
result in whole UI graphs to be locked in memory.
The same does not occur with bindBidirectional. The javadocs describe
this type of binding as "bind with inverse", which sounds to me it is
mere short-hand for doing X.bind(Y) + Y.bind(X), if that were allowed,
resulting in both X and Y's lifecycles to be bound to each other.
Yet, that's not what happens. With a bidirectional binding, either X
or Y can go out of scope, and the binding dies with it, which is a
very nice feature and an important consideration when choosing the
type of binding that it deserves some mention in the docs.
Using bind() seems to be the default that is used everywhere, because
it is short and nice -- I'm however thinking my life would have been
much easier had I used bindBidirectional as the "default" binding
everywhere in my code -- I'm pretty sure most of the bindings I did in
the past could have been bidirectional without any consequence. In
complex cases with many unidirectional bindings (that maybe could have
been bidirectional without impacting the result), I resorted to using
a helper class that keeps track of all the bindings created so they
can all be unbound with a single call to avoid creating somekind of
memory leak.
2) For bi directional bindings, it is unclear which value will be the
final result of the two bound properties (especially confusing in
Bindings.bindBidirectional). X.bind(Y) will mean X takes the value of
Y as the direction of the binding enforces it. X.bindBidirectional(Y)
or Bindings.bindBidirectional(X, Y) have no direction and it is
unclear whether, initially, the result will be the value of X or the
value of Y.
--John
