Forum Controls
Spotlight Features

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

NetBeans 6: Matisse Updates

NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed.

Introduction to Groovy Part 3

In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.

Easier Custom Components with Swing Fuse

Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.

Benchmark Analysis: Guice vs Spring

Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies: 14 - Pages: 1  
Threads: [ Previous | Next ]
  Click to reply to this thread Reply

Beans Binding (JSR 295) & Properties on JDK7

At 8:47 PM on Sep 27, 2007, Daniel MD wrote:

The Beans Binding 1.0 release was made public on the beginning of this past month. This had immediate repercussion on several blogs about properties support as a language feature. Rémi Forax's blog entry - Mixing property language support and bean bindings - has some interesting comments on the way the Beans Binding and Properties mix.

I admit I was confused with the code. I don't understand how this is better (for GUI design)than using getters and setters, do you really have that many places where you need to bind a propriety in such a way as Rémi's code shows:
    LangProperty<MyBean,String> labelProperty =
        LangProperty.create(MyBean#label);
    
    JLabel label = new JLabel("Label:");
    JTextField field = new JTextField(20);
    Bindings.createAutoBinding(READ_WRITE, 
        bean, labelProperty,
        field, BeanProperty.create("text")).bind();
    
    JLabel anotherLabel = new JLabel("Another label:");
    JTextField anotherField = new JTextField(20);
    Bindings.createAutoBinding(READ_WRITE, 
        bean, labelProperty,
        anotherField, BeanProperty.create("text")).bind();

Here you have two labels binded to the labelProperty property, that uses MyBean, to change it's value:
 public static class MyBean extends AbstractBean {
    property String label bound;
    
    private <B,T> void propertyChanged(java.lang.Property<B,T> property,Object oldValue,Object newValue) {
      firePropertyChange(property,oldValue,newValue);
    }
    
    @Override
    public String toString() {
      return "label "+label;
    }
  }

This is an example of how to do something that is much simpler by using setters and getters. Anyway, that is not the point, since this is simply a proof of concept example. Then I read Stephen Colebourne's - Java 7 - Update on Properties - this helped understand the role of properties a little better. Moreover, I can see how this could be useful for GUI data-driven components like data tables (JTable).

But, other than that (no small achievement), I can't see a point where properties will make swing component management easier, i mean that's a lot of syntax sugar to change a couple of labels... do you?
1 . At 12:58 AM on Sep 28, 2007, Ronald Miura wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

For what concerns the language property support proposal, I'm more interested in the reference literals for properties and methods (Class#property), than some 'magic' keyword for creation of bound (which trigger events) properties.

The first will help a lot, at any place where we use strings to 'wire' things today.

On the other hand, I think that this idea of adding a 'property' keyword that generates bound setters and getters, may save some keystrokes for the cost of making things more complicated, 'hard-coding' rules about how events are triggered (it gets really fuzzy if you consider vetoable/indexed/validated/implicit properties).

About the integration of language property literals with beans binding, I think it'd be just a matter of creating a LiteralProperty class, equivalent of BeanProperty or ELProperty (I suppose this abstraction exists exactly for this purpose). For the 'automatically bound' properties, as I already said, it's not a good idea. If it just generated getters and setters (no events built-in), it probably won't hurt too much, but won't be a huge gain either.

Whatever...
2 . At 1:00 AM on Sep 28, 2007, Ronald Miura wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

Well, 'LiteralProperty' is the 'LangProperty' in Stephen Colebourne's post :)
3 . At 2:33 AM on Sep 28, 2007, Shai Almog wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

See our https://bean-properties.dev.java.net/ project, it shows how properties can actually become far more useful once you move forward to "property is an object".
GUI's can generate themselves and binding in todays code is type safe/uses references directly e.g. real code:
binder.bind(myBean.myProperty, myTextField);


This works in todays bean properties with Java 5 compatibility and no language change... You should see what we do for ORM ;-)

BTW our project is finalizing the last details for a milestone 1 release which will be followed with announcements and presentation.
Shai Almog vPrise Software makers of vPrise Workgroup http://wg.vprise.com/ founder of bean-properties the leading OSS properties implementation in Java https://bean-properties.dev.java.net/
4 . At 12:04 PM on Sep 28, 2007, Richard Bair DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

> For what concerns the language property support
> proposal, I'm more interested in the reference
> literals for properties and methods (Class#property),

I agree this is a very compelling reason for me to support language level property support.

> On the other hand, I think that this idea of adding a
> 'property' keyword that generates bound setters and
> getters, may save some keystrokes for the cost of
> making things more complicated, 'hard-coding' rules
> about how events are triggered (it gets really fuzzy
> if you consider vetoable/indexed/validated/implicit
> properties).

Oh man, I disagree here! We're talking about going from:

private String name;
 
public void setName(String name) {
    String old = this.name;
    this.name = name;
    firePropertyChange("name", old, name);
}
 
public final String getName() {
    return name;
}


to:

public bound property String name;


or some similar syntax. We're not just saving "some" keystrokes, we're looking at a reduction of 203 chars to 34 chars, or a a 597% decrease in the amount of code (if I did my math correctly). It is easier to write, easier to read, easier to document.

More important than all that is the fact that getting bound property notification _correct_ is rather tricky. I believe I have it correct above, but you have to be careful. For example, if it had been an array that had been changed instead of an immutable String, then you have to be sure to copy the array so as not to expose your class invariants to listeners of the property change event. You have to make sure your getter is final or you cannot refer to the field directly but would have to go through the getter for every call (or a subclass may foil your code by override the getter to return something you don't expect, and you'd pass the wrong data to clients via the property change event).

With the current java beans event model, it is rather hard to get it right. And much harder to get indexed properties and such right. I'd much, MUCH rather have this problem dealt with at the language level, where it makes it much harder for me to code my class incorrectly.

In my opinion, language level properties are pointless if they don't solve this problem. Perhaps it will also require a new version of JavaBeans and a new JavaBeans event model. I don't know. But there isn't a point to adding properties to the language if all it does is trivialize this idiom:

private String name;
 
public void setName(String name) {
    this.name = name;
}
 
public String getName() {
    return name;
}


Richard
5 . At 12:28 PM on Sep 28, 2007, Mikael Grev DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

> "or a a 597% decrease in the amount of code".

Wow! A decrease of more than 100% is nothing short of amazing! Does it mean that if you use a property you get five other properties for free? ;)

(sorry, couldn't resist)

Other than the percentage calculations I am in 100% agreement with you. This does however mean that we need per-instance properties, which JSR 295 doesn't have..

Cheers,
Mikael Grev (grev at miginfocom dot com)
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
6 . At 1:08 PM on Sep 28, 2007, Shai Almog wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

> > For what concerns the language property support
> > proposal, I'm more interested in the reference
> > literals for properties and methods
> (Class#property),
>
> I agree this is a very compelling reason for me to
> support language level property support.

I respectfully disagree.
Language level properties are not a requirement to support type safe compiler checked properties. In fact all current language level support proposals are not nearly as safe/powerful as bean-properties on several fronts. The main problem they have is trying to map to the current JavaBean spec which was a simple patch designed to enable Java GUI builders in JDK 1.1 era. Its time to move forward from Plain and Old to something more advanced.

> Oh man, I disagree here! We're talking about going

I respectfully disagree with you. You are focusing on the word "keystrokes" and completely ignoring his other points such as:
1. Indexed properties don't work in current JavaBeans why would they work with the new keyword? Have you ever worked with them?
There is a reason Hibernate etc. use collections rather than indexed JavaBean properties. Don't get me started about the lack of mapped properties etc...

2. Event handling/veto code is a mess to write, but by hardcoding it and all the edge cases into the compiler it will become FAR worse!
Specifically your syntax:
public bound property String name;

is wrong. Bound seems like an incorrect keyword here since a property doesn't know what it is bound to... If you mean observable or something of that sort then you would need additional code to dispatch/bind listeners since the current API is not designed around these ideas.

Furthermore, current language changes do not offer any significant saving over bean-properties in terms of lines of code. In fact bean properties saves more lines of code! Specifically when it comes to observability where bean-properties do not need a dispatching mechanism since that can be generalized in the API level.
Shai Almog vPrise Software makers of vPrise Workgroup http://wg.vprise.com/ founder of bean-properties the leading OSS properties implementation in Java https://bean-properties.dev.java.net/
7 . At 1:48 PM on Sep 28, 2007, Ronald Miura wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

What about read-only properties, 'side-effect' properties, vetoable properties...

For example, consider a 'quantity' property that changes only when something is added to a 'items' indexed property.

First, there should be some way to specify if a prop has a setter, a getter, both, or none. 'quantity' has no (public) setter.

Second, What operations would be exposed for an indexed property? 'addItem', 'removeItem', 'addItems', 'containsItems', etc., or just a 'getItems' which returns a mutable collection (good bye, encapsulation)?

Third, in what order the events should be triggered? I once coded a CGLib-based class that enhanced simple beans (with no concern about events) to support listener registration and automatic event handling. But it just didn't work properly, because of the case like the above (but it wasn't an indexed property, but a property that triggered a change in another one). I assumed that the right time of firing an event is after the 'super' setter method was called, but in this case, the correct behavior was 1. change the property 'A' value; 2. fire event 'A changed'; 3. change the property 'B'; 4. fire event 'B changed'. But what happened was 1,3,4,2, because the event of the first change was fired only after the method returned. I can't see how a magic 'bound property' keyword would solve this kind of thing.

So, we do agree. I was talking about the current JavaBean spec in my comment. If you are truly considering a complete remake of it, maybe it could work. But, it would mean that it would be potentially incompatible with the current approach, in both obvious and subtle ways. A much harder problem than it looks at first sight.
8 . At 2:19 PM on Sep 28, 2007, Daniel MD wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

Yeah, i like that a bit better. The addition of the property keyword, seems avoidable. Besides the compelling reason of easier refactoring because you stop having String everywhere. Is this a good enough reason to introduce more syntax sugar?

I mean most IDEs generate the setter getters, so it's not like you really have to type that much, since the code is auto-generated. I am still not sold on the usefulness of adding the property keyword, perhaps it's just my style of code that is usually more graphic and less data/business oriented... nevertheless your project appears to be an interesting, workaround.
9 . At 5:10 PM on Sep 28, 2007, Richard Bair DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

Hi Shai!

To quote myself: "Perhaps it will also require a new version of JavaBeans and a new JavaBeans event model."

Pretty much your entire post was based on the assumption that I thought a language level feature should work within the bounds of the current JavaBeans API. I do not.

> Furthermore, current language changes do not offer
> any significant saving over bean-properties in terms
> of lines of code. In fact bean properties saves more
> lines of code! Specifically when it comes to
> observability where bean-properties do not need a
> dispatching mechanism since that can be generalized
> in the API level.

I suspect we will never agree on this point. I am a big fan of most of the Java 5 language features, though I know you have been quite vocal against them.

My feeling is that properties are such a fundamental part of programming (especially of programing GUIs) that having proper language level support and a proper component model is a really big deal. Everyone I know who is familiar with JavaBeans agrees that the basic event model has issues. We all know that everybody ignores indexed properties. We all know that vetoable properties are seldom used. We also all know that bound properties, if you will pardon the phrase, is a really big deal. We also know that often a property causes a change in state of a component that affects multiple properties, and thus some form of event chaining comes into play, and so forth.

All of these problems are solvable. And no matter how they are solved, in the end, a nice, concise, language feature will be a benefit to the java community.

Richard
10 . At 5:20 PM on Sep 28, 2007, Richard Bair DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

Hi Ronald,

> What about read-only properties, 'side-effect'
> properties, vetoable properties...

All solvable problems. Clearly, there will be a significant portion of properties (20%?) that will require custom code. However the vast majority, in my experience, are simple straightforward bound properties.

> First, there should be some way to specify if a prop
> has a setter, a getter, both, or none. 'quantity' has
> no (public) setter.

Yep.

> Second, What operations would be exposed for an
> indexed property? 'addItem', 'removeItem',
> 'addItems', 'containsItems', etc., or just a
> 'getItems' which returns a mutable collection (good
> bye, encapsulation)?
>
> Third, in what order the events should be triggered?
> I once coded a CGLib-based class that enhanced simple
> beans (with no concern about events) to support
> listener registration and automatic event handling.
> But it just didn't work properly, because of the case
> like the above (but it wasn't an indexed property,
> but a property that triggered a change in another
> one). I assumed that the right time of firing an
> event is after the 'super' setter method was called,
> but in this case, the correct behavior was 1. change
> the property 'A' value; 2. fire event 'A changed'; 3.
> change the property 'B'; 4. fire event 'B changed'.
> But what happened was 1,3,4,2, because the event of
> the first change was fired only after the method
> returned. I can't see how a magic 'bound property'
> keyword would solve this kind of thing.

"bound property" wouldn't be magic. It would be shorthand, just like the enhanced for loop. I think it is clear that there needs to be support in some fashion for developers to write custom code for a property's accessor and mutator. But none of this means that language level support would end up too unwieldy or is in some way broken.

> So, we do agree. I was talking about the current
> JavaBean spec in my comment. If you are truly
> considering a complete remake of it, maybe it could
> work. But, it would mean that it would be potentially
> incompatible with the current approach, in both
> obvious and subtle ways. A much harder problem than
> it looks at first sight.

I'm not in charge of the language feature in any way. But in my opinion, what it boils down to is the JavaBeans component model and event specification. Everyone I know who understands this space agrees that the old spec is old and doesn't fit our needs very well.

As for compatability, that waits to be seen. Introspector might provide the cover we need to bridge the "old" pattern based approach with a "new" language/API approach.

I guess my point in all this is that I, personally, would LOVE to program with language level properties. I would love to get rid of a ton of boilerplate that I'm always writing. I'd love to have events that made sense, and solve a lot of the problems I've personally had with the current beans spec.

Richard
11 . At 5:46 PM on Sep 28, 2007, Shai Almog wrote:
  Click to reply to this thread Reply

Re: Beans Binding (JSR 295)& Properties on JDK7

Hi Richard,

> To quote myself: "Perhaps it will also require a new
> version of JavaBeans and a new JavaBeans event
> model."

Forgive me but I assumed you meant a new event model such as the one discussed by Remi which isn't really new.
Would a "properties as objects" model fit this approach?
If so why not work with something like bean properties which solves all these use cases and can work in parallel with a language change?

> Pretty much your entire post was based on the
> assumption that I thought a language level feature
> should work within the bounds of the current
> JavaBeans API. I do not.

Only partially, some of it was referring to your claim that a language change was necessary.

> I suspect we will never agree on this point. I am a
> big fan of most of the Java 5 language features,
> though I know you have been quite vocal against
> them.

I am a pragmatist first and ideologist later, bean-properties uses Java 5 features all over the place and forces you to use generics. I am not against language change, I am against rampant unnecessary language changes.
The property keyword is not something I'm in favor of because I don't think its necessary. However, if it does eventually happen I would like the solution to look more like bean-properties (properties as objects) and not at all like current beans which are just terrible.
In this case the difference between the property keyword and no property keyword would be very low.

> My feeling is that properties are such a fundamental
> part of programming

If you know its so broken, why don't you use or advocate bean-properties?
This is a solution available right now, completely free (BSD no advertising clause which is as lenient as it gets), 100% compatible with existing beans etc...
I think once you guys actually start going through the code and the tutorials and compare it to JSR 295 you would understand properties far better than any theoretical argument can cover. I tried joining the 295 discussions but the property approach is so simplistic there that I couldn't even explain to Jesse why I think its broken.

> All of these problems are solvable. And no matter how
> they are solved, in the end, a nice, concise,
> language feature will be a benefit to the java
> community.

The problem with this approach is the immediate nature of a language change. Few people play with a language change before it becomes a part of the language, an API can always be deprecated but language changes are set in stone. By bundling such a huge keyword with so many fundamental changes to the way Java is doing things today you are advocating a HUGE risk of leaping ahead without public process. If a language change comes it should be clearly defined and the best way is to publiclly iron out the API on which the language change will stand.
Shai Almog vPrise Software makers of vPrise Workgroup http://wg.vprise.com/ founder of bean-properties the leading OSS properties implementation in Java https://bean-properties.dev.java.net/
12 . At 7:23 AM on Oct 1, 2007, dario novakovic wrote:
  Click to reply to this thread Reply

Re: beansbinding, benas-properties and iBatis, Hibernate...

Upon a quick look, I'd say this beans-properties and beans binding both will not work with persistence frameworks like iBatis and Hibernate. iBatis expect properties to be set/get using classic setters and getters and this is a bit different. Does anyone think this could work with iBatis?
13 . At 7:37 AM on Oct 1, 2007, Shai Almog wrote:
  Click to reply to this thread Reply

Re: beansbinding, benas-properties and iBatis, Hibernate...

> Upon a quick look, I'd say this beans-properties and
> beans binding both will not work with persistence
> frameworks like iBatis and Hibernate.

Bean properties would work with JPA (e.g. Hibernate, toplink and others) when using property based injection rather than field based injection. This requires that you add a getter/setter per property and annotate that... obviously a bad solution.

I started working on Hibernate bindings but that was too much work so Glen Marchesani and Myself created an ORM tool specifically designed for bean properties with many advantages over JPA in the syntax department. For further details check out the website:
https://bean-properties.dev.java.net/

I will try to post tutorials etc... once we hit milestone one hopefully this weekend.
Shai Almog vPrise Software makers of vPrise Workgroup http://wg.vprise.com/ founder of bean-properties the leading OSS properties implementation in Java https://bean-properties.dev.java.net/
14 . At 5:00 AM on Oct 2, 2007, Christopher Brown DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Properties on JDK7

All we really need is to promote the concept of properties to language level, as in C#. Like this:

public property String foo {
set() { // for writeable properties
// validate and set value
}
get() { // for readable properties
// return or calculate value
}
}

...making this possible:

System.out.println(object.foo)

...and this:

object.foo = "bar"

...and making it possible, via reflection, to obtain javabeans properties and the above language-level properties, and pass references to them around, to event handlers.

The object#foo syntax is just awful and confusing to anyone except people that really love compilers, grammars, and making things more complicated and abstract than they need to be.

Oh, and method pointers would be nice, as a better solution than listener interfaces that require lots of anonymous-or-otherwise classes.

- Chris

thread.rss_message