Rémi Forax's Blog

Property and bean spec

Among the questions about my property proposal and its implementation. One can be answered easily.

Why don't provide property change support ?

Because there are several ways to implement a property change support depending on what you want.

I've try to categorize them, conbinations are possible:

• Listener and event can be at least the following couple: PropertyChangeListener/PropertyChangeEvent, VetoableChangeListener/PropertyChangeEvent, an PropertyChangeListener,/IndexedPropertyChangeEvent, or the swing lightweight ChangeListener/ChangeEvent.
• Register/unregister listeners Listeners are stored in a collection, but which one ? A list or a set. Is the collection threadsafe, using synchronized blocks, locks or other concurrent mecanisms ? The traversal is in ascending, descending or any order.
• Listener and thread The listener method is called by the current thread, another thread (using by example an executor) or a special thread (like the EventDispatchThread).

I hope you are convinced.

Comments

• Remi, if you are trying to find answers to all these questions ONLY through your proposal, I don't think you'll find ones (or good ones at least). Your proposal is just one piece of the puzzle in the overall solution. The overall solution will almost definitely have an annotation aspect to it, as well an enhanced JavaBeans spec aspect to it. I think your proposal, in combination with Mikael Grev's one, plus whatever the bean spec can give us is a good start. This how in my humble opinion how should your approach be to answering these questions.

  Posted by: mikeazzi on January 08, 2007 at 02:51 PM

• why can't you implement hard referenced listeners within the property spec to automate all of this extra fuc? To handle the other cases, go ahead and implement wrapper proxies and executors via delegate assignment to the property spec implementation?

  Posted by: jhook on January 08, 2007 at 03:03 PM

• Perhaps a more flexible implementation would be handy. Nothing in this syntax is a real suggestion, only the idea is:

  public property(NotNull.class) String name;

  NotNull has to implement PropertyStrategy, which is API-provided.

  
  class NotNull implements PropertyStrategy<String>
  {
  public boolean set(String value)
  {
  if (value==null)
  return true;

  throw new IllegalArgumentException();
  }

  public String get(String value)
  {
  if (value==null)
  throw new IllegalArgumentException();

  return value;
  }
  }

  
  And PropertyStrategy:

  
  interface PropertyStrategy<T>
  {
  /**
  @return true if the value should be stored in the object, false otherwise.
  */
  boolean set(T value);

  /**
  @return the property's value, or throw an exception.
  */
  T get(T value);
  }

  
  The idea is that there is a way of customising how properties are implemented, without lots of boilerplate.

  Posted by: ricky_clarkson on January 08, 2007 at 04:07 PM

• Remi,

  Not convinced! :-)

  Reason 1 and 2 that you listed seem contrived. PropertyChangeEvent/PropertyChangeListener is the one primarily used in practice. I'm interested in solving the 80% case here, and I think that is clearly PCE/PCL. Reason 2 is easy enough -- rely on PropertyChangeSupport. However...

  Reason 3 is a good point, and is related to #2. Basically, do we provide a convenient way to override the firePropertyChange task, such that you could fire on the EDT rather than on whatever random thread set the value, etc.? In this space, perhaps Mike is right, and using an annotation makes sense.

  Overall, not something I'd relegate to the "too hard to solve" box. And still something I consider absolutely crucial. ie: Properties will be useful, but not killer, without it.

  Posted by: rbair on January 08, 2007 at 04:42 PM

• Though, for sure, all this code generation stinks. Generating a getter/setter is ok, but I'm leery of generating addPCL, removePCL, firePCE, etc etc. Eeek.

  Posted by: rbair on January 08, 2007 at 04:47 PM

• 
  Ricky, i've to think about your idea but i would prefer
  to use instance instead of class.

  PropertyStrategy strategy=...
  public property(strategy) String name;

  
  Richard, i think the bean spec can be changed to handle
  that or perhaps it should be a part of the
  JSR 295.

  I've planed to introduce new methods in java.lang.Class,
  getProperties(), getProperty(String name), etc.
  so it could be the basis of a default property strategy class
  proposed by ricky.

  Rémi
  

  Posted by: forax on January 09, 2007 at 03:10 AM

• Rémi,

  That's fine; the only benefit of making it a class name is that it's then easier to reason about statically (e.g., to prevent a null being passed to a NotNull property), but that's possibly beyond the scope of this discussion.

  Making it an instance would be good for flexibility, but then there's a recursive problem. You wouldn't be able to replace the strategy at runtime without more syntax (e.g., name::strategy=new OtherStrategy()). Making it a class name might actually be the simplest way, I don't know.

  I don't like the term Strategy though, even though I wrote it!

  Posted by: ricky_clarkson on January 09, 2007 at 04:44 AM

This work is licensed under a Creative Commons License.