Skip to main content

Let's fork BeansBinding

Posted by fabriziogiudici on March 25, 2009 at 2:13 AM PDT

I think that most of the interested people have understood what I'm going to say. BeansBinding (aka JSR 295) is a good module to bring the magic of property binding into Java. While it's far from being so elegant as binding in JavaFX (where binding has got language support), to me it's a good library doing its job well. Also, NetBeans has got support for it in its visual editor (former Matisse). I'm personally using it a lot - it also looks reasonably stable, even though I've filed a bug against it. People with more complex needs are complaining about some more serious issues or missing features. I myself have developed a few small classes that help me a lot in some cases (managing the EDT, demarcating transactions) and probably could be contributed back.

The problem is that the API has not been developed since late 2007. Unfortunately it's a story that sometimes occurs with Sun, probably because Shannon Hickey is busy doing other things. This is not bad per se, as we all understand the current Sun status and effort on projects that they presume critical as JavaFX (and I agree with them). What I find silly is that they don't communicate about the problem. How can you critically use a product if you don't know how much it will be supported in future?

The latest paradox is that a few days ago Eclipse guys started advertising their own binding stuff on the BeansBinding mailing list - and still no reaction from Sun! Get me right - there's nothing wrong or immoral in what the Eclipse guys did. We live in a open community and there's competition - "it's the economy, stupid". But I find it silly to see the competitor taking away customers and still sit in silence.

So, I'm now going to fork BeansBinding and maintaining it on my own. I hope/presume that there is some other guy willing to do that, so it will be a genuine community effort. It doesn't seem a hard task, since the code looks clean (more info after I run FindBugs on it), there are 126 classes in total, of which only 43 are new, the others a forked, patched implementation of the EL language. I hope that we are able to get the patches incorporated into EL (and maybe in the latest 1.5 years this has been already done). There are just a handful of tests, so the first thing to do is to give the project a good coverage.

The idea is to keep the new thing under the original license (LGPL) and the same packages / classes names, so it can be dropped in as a replacement of the original (keeping compatibility also with the NetBeans visual designer). Extensions could be put initially in a separate JAR file; should Sun wake up in the near future, this would facilitate a re-join. I'm going to open the project on Kenai.

The only thing that is not clear to me is how to name the project, so please give me suggestions. I've only a trivial idea such as BeansBinding2. Also, it's the first time I fork a project, so I probably have to do some due diligence for the bureaucracy.

Thoughts?

Comments

Follow up to: http://weblogs.java.net/blog/fabriziogiudici/archive/2009/03/beansbindin...

Also, +1 for "fork and beans"--awesome.

Fabrizio, you'll find my e-mail address on the bugs.eclipse.org address I gave earlier. If you're serious about working together on cross-compatibility please contact me. Matthew Hall

... that MYSELF alone can do ...

I'm always in favour of interoperability, so green light from me! I always hope that a few people will join actively, because it's clear that I'm alone can do just a fraction of the things here discussed.

Competition is good. Speaking personally as an Eclipse DataBinding project member, BeansBinding has been a valuable competitor (the BeansBinding core property API informed our own API design improvements in Eclipse 3.5, see https://bugs.eclipse.org/194734). Best wishes moving forward, BeansBinding is a great project. P.S. Hopefully we'll find some excuse to work together in the future, e.g. an interop project so that adopters of either project can take advantage of features in the other one?

Shannon, thanks for the PR with Sun. We're waiting for the "pop" from Sun, hoping it will really happen shortly. ;-)

swpalmer: could you provide a test case for the radio button issue ?. I can't figure out when happens and I will need to use radio buttons and binding very soon. Today, I coded a test dialog with 6 radio buttons binded to 6 beans properties without any issue. I would like to reproduce your bug.

The radio button issue was not in the issue tracker, so I just filed it now: https://beansbinding.dev.java.net/issues/show_bug.cgi?id=61

"fork and beans" - I love it. What about "BeansForkForever" aka "BFF" ;-) FYI: I've spoken with the team at Sun and I understand someone will be popping in to this discussion shortly.

Nice news. I was looking at the JSR303 yesterday and how if it could be integrated with BeansBinding. Seems no so easy but it would be very good.

How about "fork and beans"?

BetterBeansBinding?

Great idea. If you get some traction I would be happy to replace beans binding in my Swing JavaBuilder project with a maintained version. Enhancement request #1: add validation for EL expression, so that if they point to an invalid or non-existent property it doesn't just fail silently but actually throws an exception or something. P.S. Use git! :-)

Great initiative! I really hope you'll succeed! I feel that next after the application framework (JSR 296), binding is the most important missing part of the Swing puzzle.

@dags Yes. It's part of the "due diligence"; also to check whether the current project has clear IP. @swpalmer. Don't worry, as NetBeans compatibility is also a requirement of mine. If Sun let us avoid doing a fork, I would be happy as well. Is your stack overflow problem already part of the filed BeanBindings issues?

Would be great if we can avoid a fork. In any case, maintaining compatibility with NetBeans and the App Framework are really important to me. (I would say don't bother if you can't at least meet that requirement.) Great to see this project get some attention again. If you make binding to a radio button easy to do without getting a stack overflow I would be very happy :-)

If allowed, that seems to be the best option. I guess there will be some kind of signed agreement involved. I had to sign an JCA even for small swingx contributions.

"Perhaps they'd consider letting you work under THE BeansBinding project. " I was thinking of it, but sure you should have some better channels to ask for. Thanks for the effort. Also the documents you're talking about would be very important too, of course. I'm waiting for a few days before going on with the fork, in case Sun's answer is positive. Best luck for your new job, Shannon, and thanks for your comment here!

Hi friends! It's been a while, and I definitely miss working with you. And I feel bad that I wasn't able to see Beans Binding through to completion. The good news (for me) is that I'm really happy doing something new :-) For those wondering, I am indeed working at Adobe, and I'm still in touch with Chet and Hans. However, my job has me working on applications for acrobat.com (see acrobat.com or ideas.acrobat.com). I'm definitely working IN Flex, just not on the SDK. As to the idea of forking Beans Binding, it's really nice to see that it will continue to be worked on. I hope that when Sun has the cycles they'll be able to pull back in what you've got. If I may suggest it, it would be fantastic if you got someone at Sun to work with you on this effort. Perhaps they'd consider letting you work under THE BeansBinding project. I'm sending an e-mail to the project leads now and asking them to respond to this forum. When I departed, I wrote up a handful of documents on what I saw remaining to be done on the project. Would be awesome if they could share that with you too. I do want to comment on something that Karsten mentioned. I actually don't agree with pulling out the validation from the chain. As I see it, there's two levels of validation. Consider a form with a zip code and a city. Level 1 validation would validate that the zip code is numeric, the right number of digits. This would be handled by the validator in the binding chain. The second level of validation happens before saving. This involves validating the entire group as a set. In this example, ensuring that you have the right zip code for the city they've entered. Make sense? Well, it's late here and I'm hitting the hay. Take care!

Departure message was posted in users@beansbinding.dev.java.net.

I read tons of blogs, but I definitely missed Shannon's departure. Another reason for going on with the fork. In short, my plans are: 1. Priority number one: setting up the fork properly, with all the related stuff (tests, CI, etc...) so people are reassured that they have a reliable product they can work with. This means keeping initially the same packages and class names, so it can work with the existing code and NetBeans. 2. We will surely extend the thing, taking care of everybody's suggestion. It's not necessary to do this in a second time; we can set up a sort of incubator, as other projects do, where we can propose extensions and discuss them. The reason for which point (1) is high priority is because without consolidation we have nothing to build on. More stuff later.

BeanzBinding?

How about BeansBindingOpen as a name? That gives a nod to the origination of the project, and indicates the open source nature of things. As for changes, I see one glaring issue with the current implementation of BeanProperty - it combines two concerns: chaining of properties, and working with bean properties. I would much prefer to see two separate property implementations for each of these concerns (much easier to test, and chained properties are quite useful in their own right). I'm working on a ChainedProperty implementation now - will be happy to contribute once this forked project gets up and running.

Shannon, on 09/01/09 wrote : "But then something completely different happened: after 8 years of building toolkits at Sun, an exciting external opportunity arose that would allow me to gain a whole new set of skills...building applications! And so, while very sad to leave behind many friends and exciting projects at Sun, I made the very personal decision to leave."

Really? I'd been told he defiantly wasn't working at Adobe ..um, er not quite it seems I was actually told he wasn't working on Flex. hmm

Fabrizio, Shannon Hickey is at Adobe now along with Chet Haase and Hans Muller. Carl

Fabrizio, After I made my initial query, "shoud we do community support?" I have decided that while I like BeansBinding, I'd rather see a different approach for the project long-term. I have been toying with an "improved" API for a little bit, trying to fix that problems that I see with the BB design. So, are you going to just improved what's there, or are you going to take a hard look at the framework and possibly rearchitect it? Karl

Quite like the PropertiesBinding one no its been suggested. I know Fabrizio is using 295 for bindings other than Swing/EDT.

I have complained several times about Sun's lack of commitment with BeansBinding and AppFramework projects. That projects are of capital importance to get more desktop audience, I guess. Try to develop an accounting application using JavaFX. Maybe in a future ... So, I will try the fork, use it and cooperate when possible and allowed. Regarding the name, what about "PropertiesBinding" or similar ?.

..or SwingBindings one of the core classes in the 295 impl. and helps distinguish it purpose/target audience from other 'bean' meanings and languages. What will you do about package names? try to maintain existing ones to keep API compatibility with Netbeans 295 support? suspect that'll prove limiting quite quickly.

Very good points, Karsten. Glad that you'll keep an eye on the fork, I hoped that. PS Another simple idea for the name could be just swapping the terms: "BindingBeans".

I'll keep an eye on the fork and will try to assist and will point to issues I fixed in the JGoodies Binding. I suggest two things for the fork: 1) remove the validation option from the binding chain, because I a single-property validation is weak and requires a more powerful multi-property, multi-object validation that in turn makes the binding validation obsolete. 2) Add test cases for observing property paths; these paths are a potential source for memory leaks or unexpected behavior (e.g. if two beans are equal but not the same). Last but not least, I suggest to cooperate with the Eclipse binding, at least to share knowledge. I'll move the JGoodies Binding - where appropriate - carefully towards the Eclipse Binding API. For example I consider to introduce more fine grained methods to construct a bindable bean property. If your fork, Eclipse, and me go into a similar direction, that'll reduce the risk for binding users, and make it easier to switch. -Karsten Lentzsch

This is great news!