We currently use strings to identify attributes and many attribute values in java.text.AttributedCharacterIterator, java.awt.font.TextAttributeSet, and java.awt.im.InputMethodHighlight. Josh Bloch has suggested to use type-safe enumerations instead - see his message below. Tim Prinzing has already adopted them for the Swing text components, and not only seen a cleaner API, but also substantial performance improvements. The classes mentioned above should follow.



From jbloch@taller Fri Nov 21 17: 04:52 1997
Date: Fri, 21 Nov 1997 17:04:41 -0800 (PST)
From: Joshua Bloch <jbloch@taller>
Subject: Re: type safe enumerated types
To: trc@datsun, shannon@datsun

Bill,

   I am a huge fan of type-safe enumerated types. I think that they should
almost always be used in preference to traditional (int) enumerated types. They
are much less heavyweight than you think! In fact, they can be made to feel
lighter in weight than traditional enums. If you make them inner classes to the
class that uses them, and the user chooses to import that inner class, then he
can use the short names. He could never do this with the traditional enums, as
the "pseudo-class-name" was part of the field name (e.g., COLOR_RED).
   
   Among the advantages of typesafe enums:
   
    1) Type-Safe
   
    2) Non-extensible or extensible at the discretion of the designer.
    Both are way cool. Non-extensible guarantees that a known,
    legal value is passed int. Extensible takes advantage of the
    Java namespace to create a "magically administered" namespace for
    the extensible enumeration. Multiple organizations can extend the
    enumeration without knowledge of one another, and their extensions
    will never clash. (Try doing that with an integer!)
   
    3) As fast as traditional enums for almost all operations. (==
    can be used instead of equals, as its impossible to create two
    distinct objects that are equal; the identity hashCode works.)
   
    4) You get "printability" naturally (via Object's toString operation)
    I would assume that the internationalized equivalent also works fine.
   
    5) You can provide other operations that make sense for the class
    in questions (e.g., for Color, isPrimary()).
   
    6) You can do a type hierarchy of typesafe enums, and get high-quality
    type checking in use. This is extremely powerful.
   
    7) They can naturally be shared among classes; they aren't tied to
    to the class in which they're defined like traditonal Java enums.
    (They can be associated with a specific class at the discretion
    of the designer via inner classes.)
   
    8) You can implement Sets of these things that are, in reality, bit
    vectors and run at bit vector speeds, but provide all of the high-
    quality abstraction of Sets.
   
    9) The class can (and typically should) export a Set that is the
    "universe" of the enumerated type.
   
I know there are other advantages, but I can't think of them off the top of my
head. I know of only two disadvantages:

1) They can't be used in switch statements.

2) Sets of typesafe enums are slightly more expensive and difficult to
           create than integers whose bits are traditional enums.

The ONLY circumstance under which I'd be tempted to use a traditional enum is
when the performance of creating sets is of paramount importance. I believe
that this pattern makes traditional (int-based) enums obsolete!

   I've been planning on writing these things up for fp.liveoak for weeks, but I
haven't found the time. Hoepfully soon.
   
   As for names, you should name the class exactly what the instances represent.
 If the enums are colors, name it Color. If they're operations for you
calculator, name it Operation. If they're html tags, name it HtmlTag. If
they're HTML tags in a class called Html, make them an inner class called
Html.Tag.