Add PropertyChangeSupport to @Data for two-way databinding about lombok

[lombokissues]

👤 jacek99   🕗 Aug 12, 2009 at 14:33 UTC

One of the biggest problems in Java is the lack of proper two-way
databinding between POJOs and GUI components. it is possible, but becomes
VERY verbose since every setter needs to fire a firePropertyChange event.

I've tried to tackle this problem in my ClassBuilder utility, but your
approach is WAY better.

I've summarized the two-way binding issue here:
http://code.google.com/p/javabuilders/wiki/ClassBuilder
(see the "What is the problem we're trying to solve?" section)

it would be amazing if @ Data had an option to generate all the
PropertyChangeSupport plumbing on the class and setters...this would
singlehandedly fix in Java what Sun was unable to do for 10 years.

P.S. There should be an option to specify the type of PropertyChangeSupport
class you want to use, there are specialized types for Swing that ensure
that firePropertyChange calls are always on the EDT thread, for example.

See the Wiki link for @ Bindable (not sure if that is the API you would want
to use) or maybe

@ Data(bindableVia=SwingPropertyChangeSupport.class)

Thanks! Amazing project you have here.

[lombokissues]

👤 warchildwts   🕗 Aug 16, 2009 at 18:22 UTC

If you look through some of the discussion sections, I do believe this is in the
works. From what I can tell, instead of working with the @ Data annotation, there
will be a @ Property annotation instead.

[lombokissues]

👤 reinierz   🕗 Aug 18, 2009 at 12:07 UTC

Correct, it's in the works, there are a few discussion threads in the newsgroups about how to get this right, and
it won't be on Data, it'll be a separate annotation most likely called @ Property.

[lombokissues]

👤 jacek99   🕗 Aug 18, 2009 at 16:12 UTC

Perfect..just a reminder that whatever solution you come up with, it must allow
overriding which type of PropertyChangeSupport class is used. In Swing apps the
SwingPropertyChangeSupport is necessary, otherwise EDT violations will occur:

http://java.sun.com/javase/6/docs/api/javax/swing/event/SwingPropertyChangeSupport.html

[lombokissues]

👤 psccox   🕗 Dec 08, 2009 at 23:28 UTC

Don't forget vetoable properties, as per the JavaBeans spec.

(BeanInfo generation via annotations, e.g. for icons, editors etc would be nice too!)

[lombokissues]

👤 reinierz   🕗 Jul 25, 2010 at 00:24 UTC

Issue #180 has been merged into this issue.

[lombokissues]

👤 Greg.Matoga   🕗 Jul 26, 2010 at 17:54 UTC

Quick and dirty hack: http://code.google.com/p/lomprop/ - use the @ BindableData annotation - generates proper getters and setters, methods: addPropertyChangeListener, removePropertyChangeListener; and an initialized field $propertyChangeSupport. Resulting bean is bindable using JSR-295 (tested in NetBeans).

[lombokissues]

End of migration

[rzwitserloot]

I'm closing this, with pain in my heart.

The problem is: The 'obvious' ways to do this, which somewhat match what the community does, are, in my opinion, bad. Possibly not their fault, given that they don't have code gen in their tool box.

I do not want to introduce a feature in lombok when I know a better take is realistic.

Nevertheless, this feature clearly isn't important enough: GUIs with java aren't exactly popular. Perhaps a self-fulfilling prophecy (GUI building in java is not popular and insofar that people do it, they don't use the notion of binding properties/fields to a widget as the way to make it happen, because it's hard to set it up), but it does mean that in order to change the world, we need to be out there advocating for this newer, better way.

If the community at large is clearly shrieking out for a fix, I could be tempted in getting the soapbox out. But the 'build GUIs in java' community seems hard to reach and somewhat conservative to me: That plan seems clearly doomed to failure for me.

Which leaves us with no options. I won't accept a crappy take on properties, and a good take probably won't be understood / adopted by the community.

To make matters worse, neither I nor as far as I know @rspilker works on GUIs in their daily java travails, so the ideas we have about a really cool take on properties in java are based on academics and lack experience. They also lack the 'scratch your own itch' factor. These are on us and can be mitigated with broader community support reviewing the work and/or a contributor that does have personal experience, of course, so these aren't show stoppers. Just - not helping.