Name: krT82822			Date: 02/09/2000


java version "1.2.2"
Classic VM (build 1.2.2-I, green threads, javacomp)

The PropertyEditor support for base types and their wrappers is inconvenient
and could easily be improved:

1) A property editor for 'char' is missing.

2) Property editors for 'Boolean', 'Character' and 'Integer' are missing.

3) The property editors for other wrapper classes exist by accident
   (naming convention) only; if the ediors for 'boolean'/'int' had been
   named 'BooleanEditor'/'IntegerEditor' instead of
   'BoolEditor'/'IntEditor' they had also been found by
   PropertyEditorManager.findEditor(); the bug:
   ShortEditor.getJavaInitializationString() delivers "((short)4711)"
   while "new Short((short)4711)" or 'new Short("4711")' would be
   correct.

4) Property editors for 'BigDecimal' and 'BigInteger' are missing.

Solutions:

Rename existing base type property editors to <type>Editor, ie,
'byteEditor', 'shortEditor' etc, breaking the usual class naming
convention for good reasons.

Provide editors for wrapper classes, named <class>Editor as
usual. Naturally derive these editors form their base type
counterparts and change the getJavaInitializationString() method
only. Example:

<pre>
public class ShortEditor
    extends shortEditor {

    public String getJavaInitializationString () {
	return "new Short (" + super.getJavaInitializationString () + ")";
    }
}
</pre>

Provide charEditor:

<pre>
public class charEditor
    extends PropertyEditorSupport {

    // FIXME: How to automatically register this class? The following
    // static registration code appears to be executed only if an
    // instance of this class is created. But instantiation takes
    // place using PropertyEditorManager.findEditor(), which in turn
    // requires previous registration... [ naming convention char <->
    // charEditor doesn't help since this is a base type editor. ]
    static {
	PropertyEditorManager.registerEditor (Character.TYPE, charEditor.class);
    }

    // would have preferred this:
    //
    //     public void setValue (Object valueObject) {
    // 	       Character value = (Character)valueObject;
    // 	       super.setValue (new Character (value.charValue ()));
    //     }
    //
    // that would have thrown a NullPointerException or
    // ClassCastException, but to keep consistency with eg
    // sun.beans.editors.IntEditor we set (and later deliver) our
    // internal value unchecked;
    //
    // for that functionality, we can reuse PropertyEditorSupport's
    // setValue(), getValue(), and getAsText()

    public void setAsText (String s)
	throws IllegalArgumentException {

	if ((null == s) || (1 != s.length ())) {
	    // would have preferred more verbose version:
	    //
	    //   throw new IllegalArgumentException ("cannot convert string " + s + "
to Character");
	    throw new IllegalArgumentException ("" + s);
	}
	// PropertyEditorSupport.setValue() will also fire the
	// PropertyChangeEvent
	setValue (new Character (s.charAt (0)));
    }

    public String getJavaInitializationString () {
	return "'" + getAsText () + "'";
    }
}
</pre>

Provide BigDecimalEditor/BigIntegerEditor (left as an exercise to the
reader :-) Should be fairly easy as both classes already provide
String parsing/generation.

BTW, I don't follow your arguments in Bug 4065163 [please don't make
this report simply a duplicate of that closed BR]: "I don't think
those types [wrappers] are common enough to justify standard property
editors."

The wrappers are common enough, and the base type editors ARE wrapper
editors (except for the getJavaInitializationString() method), so the
changes/additions are trivial to implement (as shown above).
(Review ID: 100176) 
======================================================================