japitools-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Japi] Abstract enums


From: Jeroen Frijters
Subject: RE: [Japi] Abstract enums
Date: Tue, 28 Nov 2006 08:06:22 +0100

Stuart Ballard wrote:
> I discovered today what appears to be a compiler difference in the way
> certain enums are handled. The enum TimeUnit has an abstract method
> that is implemented in each of the individual enum values. It appears
> that ecj is emitting the enum type itself as abstract for this case,
> while the RI's TimeUnit enum is not abstract.

Where are you seeing this? I can't reproduce this with the versions of
javac and ecj I have installed (both mark the class as abstract).

> This may or may not be a compiler bug in either javac or ecj, but it
> does seem clear that it's not a bug in TimeUnit itself. I can't see
> any possible practical problem for any user of the TimeUnit enum from
> the fact that it's been compiled as abstract or not, since it's never
> instantiated directly anyway.
> So I think I'm going to modify Japize to treat all enums as
> non-abstract regardless of what their modifiers say - and while I'm at
> it also treat them all as final.

Agreed. BTW, doesn't this also mean that you should ignore "abstract" on
methods in an enum? After all, aren't these two enums the same:

enum E1 {
  FOO;
  public void foo() {}
}

enum E2 {
  FOO { public void foo() {} }
  public abstract void foo();
}

As an interesting aside, the VM does not actually prevent you from
subclassing an enum with a regular class. This means that coupled with
the "finalizer attack" you can actually create illegal enum values. This
was fixed in 1.6 by adding a final finalize method to java.lang.Enum.

> I'm not exactly asking for votes on
> this, because I'm fairly sure it's the right thing to do; but I'm
> sending this mail to offer people the opportunity to give objections
> before I go ahead and do it :)

Thanks for the heads up. Odd cases such as this are always worth
investigating, because sometimes they reveal incompatibilities or bugs
in related areas.

Regards,
Jeroen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]