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

Request: Want more flexibility in extending AWT

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_2.4

      Description

      From: ###@###.### (Ed Grossman)

      We at NCSA are working on a large project to build a collaboration
      environment using Java and AWT. We believe that one of the features that
      was added to the prebeta release of AWT make it pretty much unusable for
      that purpose.

      Basically, all of the instance variables were declared private, and no
      interface has been declared to allow subclasses to make changes to those
      variables. This makes the AWT pretty much inextensible by anyone other
      than the AWT developers, because subclasses have no more rights to their
      internals than any unrelated class would have.

      To be a little more specific, here are just a few extensions to AWT which
      we would like to make, and which are impossible given the current
      structure:

      1) Create a Menu object which could change the order of its items, or add a
      new item anywhere but the end.

      2) Write a descendant of Container which could sort its children in place.
      An example here would be a list of lines that had different columns, and
      the whole list could be sorted on any column (the Eudora mail handler on
      the Mac does this). Yes, you could fake this with a LayoutManager object,
      but it would be very inefficient, and still would not provide a way to ask
      for the nth line in the column. You would also not want to call invalidate
      very time you changed a line, since you knew that all the lines were
      moving, and one big invalidate call would be sufficient. It is, howver,
      impossible to get direct access to the list of children.

      3) Create an object which acts like a Checkbox (and type-checks like one)
      but doesn't look like one.

      4) As a descendant of Component, set my parent directly. There are a lot
      of cases, when you know the topology of your parents and children, when it
      is inefficient to go through the entire update chain every time you
      move/show/hide/whatever an object. Especially if there are multiple
      relocations.

      I have had fairly extensive experience with a number of toolkits on X and
      Macintosh platforms - I've even helped implement one, and none of these
      examples have been difficult in any of them. If you want the AWT to be a
      general purpose toolkit, as opposed to an applet-writing kit, these
      concerns must be addressed.

      We are also concerned by a somewhat more theoretical point. The AWT pushes
      a lot of functionality onto the native toolkits - in particular coordinate
      transformation and a lot of event handling. While this does ensure that
      the native platform look and feel is respected, it makes extension more
      difficult. Since most of the interesting code is not in Java, most
      extensions to that code will also have to be in the native toolkit, and
      thus written over for each platform. This reduces the gains Java's
      multi-platform nature was supposed to ensure.

      We hope you will carefully consider these concerns; we would be happy to
      discuss them in more detail if you would find that helpful. We have
      corresponded with Arthur van Hoff, but he doesn't seem to think there is a
      problem.

      Yours Truly,
      Ed Grossman
      Senior Research Programmer
      Software Development Group
      NCSA

        Attachments

          Activity

            People

            Assignee:
            ehawkessunw Eric Hawkes (Inactive)
            Reporter:
            duke J. Duke (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: