Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4311452

inconvenient PropertyEditor support for base types and their class wrappers

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Duplicate
    • Icon: P5 P5
    • None
    • 1.2.0, 1.2.2, 1.3.0
    • client-libs
    • generic, x86
    • generic, windows_95



      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)
      ======================================================================

            mdavidsosunw Mark Davidson (Inactive)
            kryansunw Kevin Ryan (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: