Javalobby

Fabrizio Giudici is a Senior Java Architect with a long Java experience in the industrial field. He runs Tidalwave, his own consultancy company, and has contributed to Java success stories in a number of fields, including Formula One. Fabrizio often appears as a speaker at international Java conferences such as JavaOne and Devoxx and is member of JUG Milano and the NetBeans Dream Team. Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Using JavaFX Bean Binding ... in Java!

06.12.2009
| 5816 views |
  • submit to reddit

We Recommend These Resources

My priority for working on BetterBeansBinding (BBB) is writing tests and fixing bugs of BeansBinding. Also, a few people started asking for minor enhancements, and these are for sure the high priority tasks.

BetterBeansBinding is a library for implementing property binding with Java objects. "Property binding" is about keeping two properties of two object instances in sync. BBB is a fork of the BeansBinding project, which provides the reference implementation for the JSR-295 specification.

One of the things that I have in mind for the evolution of the library is to try something to be as similar as possible to JavaFX binding. Of course, it can't be as easy as JavaFX binding, as JavaFX introduced language enhancements for that function. But something can be probably done (I've started writing some very basic hacks, not to be discussed yet).

Today, I've run into this post by Thomas Künneth that is undoubtedly worth reading. Thomas hacked around with the JavaFX binding implementation (which is made in Java) and showed how it can be used from Java applications. Of course he's aware that internal stuff in JavaFX is not officially published and should not be used in production.

I'm quoting two final questions, that I'd like to discuss in the BetterBeansBinding perspective:

  1. Does Sun allow the usage and possibly the redistribution of parts of the JavaFX runtime for non-JavaFX applications?
  2. Should we even bother? After all, there are other, more mature binding frameworks for Swing developers

Well, the answer of #1 is clear: you can't, as it is explicitly forbidden by the JavaFX license. Furthermore, being JavaFX not FLOSS, many people wouldn't use it.

Then, I'd say it makes sense to bother about it, since JavaFX binding is elegant and leads to more compact code.

What do you think?

Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Weiqi Gao replied on Fri, 2009/06/12 - 10:25am

The JavaFX Script compiler and language runtime (including the Location Framework) are Free Software (GPL v2). However there is no published interface to it, so if one chooses to use it one should be prepared to deal with the API changes inherent in internal interfaces. It is the GUI APIs and GUI runtime that are currently non-Free Software. -- Weiqi

Fabrizio Giudici replied on Fri, 2009/06/12 - 10:58am

Interesting enough. I believe that only the compiler was open sourced. Is it everything under the same Subversion repo?

Jacek Furmankiewicz replied on Fri, 2009/06/12 - 10:58am

There is no way that BBB should depend on a huge dependency such as JavaFX...that would make it harder to use it for pure Java projects. I'd say rather focus on the outstanding issues in BB, such as bugs and lack of documentation.

 Just my $0.02.

P.S. Thanks for bringing this library back to life, it's much needed.

Fabrizio Giudici replied on Fri, 2009/06/12 - 10:58am

Jacek, I agree that the dependency point is important. But having a look at the Location Framework might be inspiring... :-)

Arek Stryjski replied on Fri, 2009/06/12 - 11:14am

Maybe I should read this article more carefully, but I don't understand why someone would like to use it.

He is using:
- IntVariable not standard Java Integer, or int for model
- SwingLabel not JLabel;

If I need to rewrite the whole application to use JavaFX specific classes, why not do it in JavaFX?

I got completely lost at the end. He is implementing ChangeListener with standard anonymous inner class... I was thinking binding is about removing this kind of JavaBean/swing code.

 

 

Fabrizio Giudici replied on Fri, 2009/06/12 - 12:26pm

Arek, the point is not about using that stuff as in the mentioned article. That article is a starting point, and then we have to see whether we can get an easier way to work with it (better, with an equivalent implementation). Maybe not, maybe yes.

Thomas Kuenneth replied on Fri, 2009/06/12 - 1:23pm in response to: Arek Stryjski

Hello. As I am the author of the article on Hacking JavaFX Binding, I might be able to clarify a few things. As JavaFX Binding is based upon locations, binding will work only if source and destination variables/objects are locations. The standard Swing components (JLabel, ...) are not, so, in order, to bind them to some object we need components that are; therefor I needed to use the ones JavaFX offers (SwingLabel, ...). The same applies to non-primitive datatypes (Integer). Be be able to use binding, we need a version that si a location, hence the JavaFX type IntVariable. It is true that changing such things means a great change on the overall application. The point I am trying to make is that, if you accept that, you get data binding for quite a small price. Finally, the change listener is for instance neccessary to modify the binding, for example to negate a boolean variable. In my example this was needed because a checkbox shoul be enabled when a variable is false. Hopefully I was able to explain a few things. Regards Thomas Kuenneth

James Jamesson replied on Sat, 2009/06/13 - 12:53am

JavaFX binding offered under the hood has already been done by many in Java. It is based on well known delegation model. I do not see any fancy interesting techniques in it. However, it is wrapped up pretty well by JavaFX. I too do not see the need to blend JavaFX bean binding with Java although it sounds fancy enough.

Fabrizio Giudici replied on Sat, 2009/06/13 - 3:47am

Thanks Thomas for commenting here.

It is true that changing such things means a great change on the overall application.

Which is my point too. And as jamesjames pointed out, the core concept is not new, the new wrapper classes around variables (called Locations in JavaFX) are a "surrogate" for the lack of first-class properties in Java. Other frameworks, such as Wicket, have got similar approaches for their binding.

alopecoid replied on Sat, 2009/06/13 - 8:32am in response to: Thomas Kuenneth

Just a thought...

Perhaps AOP / bytecode instrumentation could be used to inject the stadard Java library classes (Integer, JLabel, etc) with Location implementation logic. This could perhaps avoid the need to depend directly on the JavaFX API. Also, if the API changes, this would isolate the required changes (at the instrumentation phase).

Fabrizio Giudici replied on Sat, 2009/06/13 - 9:39am

I have to correct my previous comment, the point that I intented to quote is the whole stuff (I missed the second statement):

It is true that changing such things means a great change on the overall application. The point I am trying to make is that, if you accept that, you get data binding for quite a small price.

Thomas Kuenneth replied on Sat, 2009/06/13 - 9:50am in response to: Fabrizio Giudici

the core concept is not new, the new wrapper classes around variables (called Locations in JavaFX) are a "surrogate" for the lack of first-class properties in Java

I was trying to make that point in the article, too, when I compared locations to ValueModel and Property. The thing is, if we had language-level support for binding, the underlying technical implementation would be irrelevant. I mean, it is true that JavaFX uses well-known concepts. But the JavaFX Script-developer does not care. He just binds things together.

Additionally, I am not sure if totally new concepts other the language-level support would work for Swing as we know it today. Binding does not neccessarily involve GUI components, but in many cases it does. As soon as Swing is involved, any new idea must be compatible with core ideas and concepts of that library. So my impression is that binding is just a part of a bigger picture.

Regards
Thomas

sub online replied on Fri, 2009/06/26 - 3:00am

You think I was born yesterday.links of londonCalm down! Don't get so excited. Calm down. Keep your pants shirt on! What's the hurry? Keep your pants shirt on.links of londonIt's a long story.You're overdoing it.What does it matter!Tiffany JewelleryPerfectionist.You'll regret it if you don't go.Better than nothing.When's class gonna end!I'll know when the time comes.That's a bad idea if I've ever heard one.All things must come to an end.

Ayo Bakare replied on Thu, 2009/07/30 - 7:35pm

thats pretty cool man Free Macbook | Free iPhone 3GS

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers