In fact, this is why the "base" module exists separate from "graphics", is so that you can take base.jar and reuse it on the server side. I would not anticipate that these classes change packages because that would be massively incompatible, however there is no reason you couldn't reuse the base module on the server side.
Richard On Jul 16, 2013, at 5:24 AM, Tom Eugelink <t...@tbee.org> wrote: > > Be aware that the binding of properties is lazy. That means that if a value > changes, bound properties are not updated, they only get notified of the > change. Serverside that may not be the preferred / expected behavior (binding > libraries like JGoodies always update), so it may be necessary to "short > circuit" the notification to always trigger the update. > > Tom > > > On 2013-07-16 10:54, John C. Turnbull wrote: >> I am very impressed with the JavaFX properties and bindings functionality >> and feel that it is far more general in scope than just a UI toolkit like >> JavaFX. For me, I think the entire feature should be moved to a standard >> Java package so that it can readily be used in non-JavaFX applications. >> >> >> Is there any reason such as threading issues or some form of functional >> dependency that would prevent JavaFX properties and bindings being used in a >> non-JavaFX application such as a server-side component? My testing seems to >> suggest that they work just fine outside of a JavaFX context but I would >> like to be sure. >> >> >> Any thoughts on extracting this functionality from JavaFX and moving it to a >> more general location in the Java package hierarchy? >> >> >> Thanks, >> >> >> -jct >> > >
