Re: evum constructor gotcha

Roedy Green wrote:


That is true. The JLS explicates this in ?8.9.

E.g.,

  public enum Foo
  {
    ROY, GRAHAM, BIV;
  }

is roughly equivalent to

  public final class Foo extends Enum <Foo>
  {
    public static final Foo ROY = new Foo( "ROY" );
    public static final Foo GRAHAM = new Foo( "GRAHAM" );
    public static final Foo BIV = new Foo( "BIV" );

    // all other static initialization occurs here

    private final String name;
    // any instance final variable initialized here will not
    // have any knowledge of the later static inits
    // but the constructor can see the instance variables
    private Foo( String name )
    {
      this.name = name;
    }
    // toString(), name(), etc.
  }


That's what you sort of get manually with Patricia's suggestion of a static
initializer block that goes back and fixes up what a pre-init would have done.
  IOW, Java does indeed provide a mechanism to work around the restrictions on
init order.

As Eric explained, fixing the order avoids certain problems with the approach
that you suggest. Sure, it's a compromise, but given the ability to do what
you need to without the more complicated implementation, it amounts to a
difference that makes no difference.

All right, you have to add a dozen or so lines of code. C'est la vie.

Did you read the "Discussion" block in the JLS that goes into why they chose
not to go down the route you suggest? It may not seem like a complete
explanations, though I do find it quite indicative. It does point up the
sorts of problems we'd have otherwise - then you'd be posting about the tricky
convolutions of circular references in enum and calling that "Mickey Mouse".

Mike Schilling wrote:


--
Lew