Java enums and dynamic creation

[Mike Calmus]

I am in the process of converting several custom enumeration classes to the Java 5 enum framework. This is going generally smoothly since our pattern pretty much conformed to the generally-accepted style. There are a few of these classes, though I'm struggling with. For some of our enumerated types we retrieved values from the database to populate descriptions. This isn't a problem for the named enums from this part since I can do the same lookup in a constructor. Part of the point of doing these database lookups originally, though was to have new values included in the enumeration without requiring a coding change to explicitly name new values. These implicit (from the database) enum values are the problematic pieces. Anyone have any ideas how to deal with this?

 

Thanks.

 

--

Mike Calmus

[Kfir Shay]

If the aim is only to prevent coding change in the event of value
change than you can push the data to a properties file.

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>

[Casper Bang]

It's not an unknown problem you describe, people modeling with JPA and
Enum's experience similar things. Enum's are really only beneficial
with truly static constructs, since an Enum instance on the JVM is the
perfect singleton which you can not instantiate yourself! While you
can hardwire logic to go fetch a description from some resource file,
it would be nasty putting any kind of database access down here.

An controversial solution might be to dispatch from the Enum to
elsewhere:

interface SuitDescriptor {
String getDescription(Suit suit);
};

enum Suit {

Diamonds, Hearts, Clubs, Spades;
private static SuitDescriptor descriptor;

public static void setSuitDescriptor(SuitDescriptor descriptor) {
Suit.descriptor = descriptor;
}

public String getDescription() {
if(descriptor == null)
throw new IllegalStateException("Description callback not
specified!");

return descriptor.getDescription(this);
}
}

It's really a case where extension methods would come in handy, but
Java doesn't have that yet.

/Casper

[Alexey Zinger]

If you need to be able to define a set of singletons from outside the JVM (database, config file, etc.), they're not really enums anymore.  By definition, they'll have to be dynamically instantiated and you won't be able to refer to them by any kind of identifier the Java compiler will understand.  They'll have a number of aspects in common with enums, but not that cruicial aspect of compiler being aware of the full set of enums of any particular type.  Is there then a good reason to convert what you already have and tested and presumably working to something based on Java 5 enum syntax?

Note, as someone pointed out, that if you can do away with the requirement of defining a set of enums outside your Java code, then yeah, you can load descriptors and other stuff from outside, but you'd be faced with 2 bad (in my opinion choices): load that info at class initialization time, or lazily.  The problem with the former is that it's really not nice to crash during class loading because it can manifest itself and take down parts of systems you never expected.  The problem with the latter is that once you've initialized, unless you immediately do a sanity check invocation to make sure all attribute have loaded, you expose yourself to getting inconsistent values or crashing later on at an unknown time.

 

Alexey
2001 Honda CBR600F4i (CCS)
2002 Suzuki Bandit 1200S
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net

---

From: Mike Calmus <mca...@nyx.net>
To: java...@googlegroups.com
Sent: Tue, March 23, 2010 4:30:29 PM
Subject: [The Java Posse] Java enums and dynamic creation

--

[Reinier Zwitserloot]

Couldn't agree more with Alexey. Enums are for compile-time static
information. If it isn't static at compile time, it shouldn't be
represented as an enum. The enum pattern that the actual java enum is
based on is described in detail in Effective Java by josh bloch. If
you really want to move forward and build your db-retrieved constants
on the 'enum' principle, I advise you to read that chapter and build
your own enum, modified as needed to fit with the 'fetch dynamically
from DB' concept.

On Mar 23, 11:36 pm, Alexey Zinger <inline_f...@yahoo.com> wrote:
> If you need to be able to define a set of singletons from outside the JVM (database, config file, etc.), they're not really enums anymore.  By definition, they'll have to be dynamically instantiated and you won't be able to refer to them by any kind of identifier the Java compiler will understand.  They'll have a number of aspects in common with enums, but not that cruicial aspect of compiler being aware of the full set of enums of any particular type.  Is there then a good reason to convert what you already have and tested and presumably working to something based on Java 5 enum syntax?
>
> Note, as someone pointed out, that if you can do away with the requirement of defining a set of enums outside your Java code, then yeah, you can load descriptors and other stuff from outside, but you'd be faced with 2 bad (in my opinion choices): load that info at class initialization time, or lazily.  The problem with the former is that it's really not nice to crash during class loading because it can manifest itself and take down parts of systems you never expected.  The problem with the latter is that once you've initialized, unless you immediately do a sanity check invocation to make sure all attribute have loaded, you expose yourself to getting inconsistent values or crashing later on at an unknown time.
>
>  Alexey
> 2001 Honda CBR600F4i (CCS)
> 2002 Suzuki Bandit 1200S

> 1992 Kawasaki EX500http://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://wcollage.sourceforge.net
>
> ________________________________
> From: Mike Calmus <mcal...@nyx.net>