Unfortunately, Java language doesn't allow enums to be subclassed or created via a factory.
Enums need to be statically defined at run time so that equality checks and switch statements can be resolved at compile time rather than run time. This is a Java 6 requirement. On Jul 10, 2016 7:29 AM, "Mark Murphy" <[email protected]> wrote: > Maybe we should have a standard enum template that defines everything that > belongs in the enum class. It would be easiest if enums could inherit from > each other, or if they weren't final classes, but that doesn't work. I am > thinking of some conversion from and to the simple type underlaying it, but > that doesn't work for the binary formats. Maybe the better way is to have a > conversion class that takes the various enums and converts them from/to the > various simple types. > > On Sun, Jul 10, 2016 at 2:51 AM, <[email protected]> wrote: > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=59836 > > > > Bug ID: 59836 > > Summary: Replace primitives with enums > > Product: POI > > Version: 3.15-dev > > Hardware: PC > > OS: Linux > > Status: NEW > > Severity: enhancement > > Priority: P2 > > Component: SS Common > > Assignee: [email protected] > > Reporter: [email protected] > > > > This is a aggregate bug for recent changes in classes from using short or > > int > > to using enums with codes. > > > > Benefits: > > * self-explanatory usage rather than needing to list the valid constants > > in the > > javadocs > > * easier to distinguish arguments in function signatures (not just a 5 > > ints) > > * clearer error messages, no functions needed to convert code to string > > * free range checking (less boiler plate code that does the same) > > * type safety > > > > Drawbacks: > > * some permgen overhead > > * type checking execution overhead > > > > Overall, this seems like a good thing. > > > > In effort to maintain backwards compatibility, the following is > suggested: > > > > If there is currently > > int getSomething(); > > void setSomething(int); > > > > Then we should add > > enum getSomethingEnum(); > > void setSomething(Enum); > > > > And deprecate > > void setSomething(int); > > int getSomething(); > > > > It's a bit tricky handling getSomething/getSomethingEnum while > maintaining > > backwards compatibility because at some point the signature will abruptly > > change. Both getters should be offered for a while with a note > encouraging > > users to use the constants or enums rather than using literal values. > This > > is > > good coding practice anyway to not hard-code literal values, but is > > especially > > important with regard to backwards compatibility here. > > > > At least 2 releases later, but not later than POI 4.0: > > Delete void setSomething(int); > > Delete int getSomething(); > > Rename enum getSomethingEnum(); to enum getSomething(); > > > > In the end, we will have > > enum getSomething(); > > void setSomething(enum); > > as the only two methods. > > > > -- > > You are receiving this mail because: > > You are the assignee for the bug. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
