Josh - sorry to hear that. I was hoping you would be interested because this
is a nice way to implement your Enumeration pattern once and reuse the
implementation.
I have nothing against the enum facility in Java 1.5, but don't want to have
to keep re-implementing serialization and property support. Hope you'll
reconsider.
Thanks,
- John
On 6/23/06, Joshua Bloch <[EMAIL PROTECTED]> wrote:
John,
I am not interested in this. It doesn't appear to play well with Java's
current enum facility, which has shown itself to work very well in practice.
Josh
On 6/22/06, John Kaplan <[EMAIL PROTECTED]> wrote:
>
> Hello All,
>
> I've been working on a Java card playing program in my spare time, and I
> figured out something about Enumerations that may be of general use.
>
> The issue is if you are working with concepts like card ranks and suits
> in a non-trivial application, you want them to be comparable, serializable,
> and have their visual aspects defined in properties, not code. In the
> classic Enumeration pattern, you would re-implement the methods needed to do
> this stuff for each class, along with iterators and lookup methods.
>
> I figured out a way to code up an Enumeration base class that takes care
> of all the excise tasks for properties, serialization, hashing, comparing,
> etc.. This class allows you to extend as many subclass enumerations as you
> want, and it automatically keeps all of the enumerations in their own name
> and number (ordinal) spaces with no runtime penalty.
>
> To extend the current implementation, you have to override 3 one-liner
> methods in your subclass (the constructor and methods to look up enumeration
> instances by name and ordinal). I think I can further simplify that with
> annotation processing so you only have to indicate if you want the default
> overrides or variations. Other possible enhancements include allowing
> injection of alternate serialization options or ordinal sizes. (It currently
> uses a byte-sized ordinal because most cases I could think of don't have
> hundreds of enumeration constants, but they often have need of conserving
> space in databases.)
>
> I also think there's a way with annotation processing to specify default
> properties in the class file without having to create/edit a separate
> properties file, and that may be generally useful outside of enumerations.
>
> So, any interest in being involved with a commons project for such a
> thing, or in using it if delivered? I am not sure of the number of
> committers required or the sponsorship/championship needed for such a small
> thing in the Commons, so any advice would be appreciated. I am willing to do
> all the coding, testing, and documentation if need be, or to share with
> anyone else interested in contributing according to Commons guidelines.
> Below is an example of a subclass.
>
> Thanks,
> - John
>
> public final class Suit extends Enumeration
> {
> protected static final long serialVersionUID =
> Enumeration.serialVersionUID;
>
> public static final Suit noSuit = new Suit( 0, "X" );
> public static final Suit clubs = new Suit( 1, "C" );
> public static final Suit diamonds = new Suit( 2, "D" );
> public static final Suit hearts = new Suit( 3, "H" );
> public static final Suit spades = new Suit( 4, "S" );
>
> private Suit( int ordinal, String name )
> {
> super( ordinal, name );
> }
>
> public static final Suit fromOrdinal( int ordinal )
> {
> return (Suit) noSuit.getFromOrdinal( ordinal );
> }
>
> public static final Suit fromName( String name )
> {
> return (Suit) noSuit.getFromName( name );
> }
> }
>
>
