Target milestone was changed from '3.4' to TBD.

Target milestone was changed from '3.4' to TBD.

reassigne to Tim, new owner of property editors.

There is a very clean, easy solution that requires no changes in
the core DataObject editor.  And since it appears to be 
decided that DataSystems in its current form is going away,
this solution has the advantage of being able to work 
transparently with any replacement for DataObjectEditor:

Write a wrapper property editor, along the lines of

class MyDataObjectEditor implements PropertyEditor {
  private PropertyEditor wrapped;
  public MyDataObjectEditor (PropertyEditor toWrap) {
    wrapped = toWrap;
  }
  public void setAsText(String s) {
    //do your validation (remember to annotate exceptions correctly!)
    wrapped.setAsText (s);
  }
  //etc...
}

Then, in your DataNode subclass:
  public PropertyEditor getPropertyEditor() {
     return new MyDataObjectEditor (super.getPropertyEditor());
}

Doesn't your solution assume I own the DataNode?  What if I pick
another module's data object?

If you're providing hints to its property editor, well, I 
would hope you own it...tell me you're not calling
setValue() on JavaDataObjects to alter the behavior of 
their property editors!  

No - I'm providing a property editor on my own node which allows the
user to pick a different JavaDataObject.  For example, imagine an
implements property which allows you to point to a JavaDataObject.

verifying.

Okay.  For that case, you should still provide a wrapper
property which can expose the original java node property,
but provide its own hints.  The fact
that a module can, in theory, play with the hints available
from a foreign node is, IMO, a fairly awful design flaw that
certainly should not be exploited.