The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Java: Dynamically Creating Class Constants

Is there a way to dynamically add class constants (i.e. public static final members) to a class based on the values stored in a database table? I should imagine that it's possible using reflection but I haven't quite figured out the details yet. Has anyone done anything like this?
John Topley Send private email
Wednesday, February 09, 2005
 
 
Why would you want to? If you were able to add a static field to a class on the fly, how is other compiled code going to read it anyways?
Gerald Send private email
Wednesday, February 09, 2005
 
 
D'oh! Good point.

Let's take a step back and look at what the actual problem is: we need to maintain certain constants in both the database and Java layers, which is a maintenance burden.
John Topley Send private email
Wednesday, February 09, 2005
 
 
Is this running in the context of a J2EE application? If so, just create a standard class with appropriate getters for the constants and have it initialize itself on startup by reading the values from the database. You can initialize on startup either using a servlet that loads on startup or creating a startup class based on whatever app server's proprietary API you are using.
Gerald Send private email
Wednesday, February 09, 2005
 
 
You can dynamically generate java classes with Apache's BCEL library.  Its pretty full featured and works very well.
Vince
Wednesday, February 09, 2005
 
 
Yes, it's a J2EE application. The list of constants can grow over time (they represent object types within the system), so every time a new one is added to the database a new getter method would have to be created.
John Topley Send private email
Wednesday, February 09, 2005
 
 
Is the constant purely a database artifact or does a new constant necessitate a code update? If the former, your just going to have to bite the bullet and go with a soft constant where the application looks it up using a string literal or some other key. I'm assuming the application knows how to pick up the new constant and work with it in a dynamic sense.

If adding a constant requires a code update, you can just add the getter method as needed. If your concerned about the number of getters, you could have a literal key constant that is passed to a lookup method, there's lots of different ways of doing this so just pick one that works best for your use case.

If it's a plugin type of thing where the class managing the constants is not updated even when new functionality is then your back to going with a soft constant and using a key to lookup up the value. You can still get some compile time checking though by defining the key as a string constant in the plugin itself so the plugin code references the constant appropriately.
Gerald Send private email
Wednesday, February 09, 2005
 
 
Implement a dictionary as a singleton.
Dino
Wednesday, February 09, 2005
 
 
Any type of item that might exist more than once in the database should be pushed into a collection object in your business logic. When your getter is called, it returns the collection, rather than an individual object in the collection.

That way, you should never need to use reflection to add new getter methods. You'll have all the getter methods that you'll ever need right from the start.
Benji Smith Send private email
Wednesday, February 09, 2005
 
 
If you absolutely must have the assistance of compile-time checking on your constants, consider a script to generate one or more utility classes based on the contents of the database. Anytime a constant is added/removed/changed in the DB, re-run the script to regenerate the constant class(es). Most source control providers today are scriptable from the command-line, so you could consider a script executed by a DB trigger upon modifications that would rev up the appropriate source-controlled version(s) of the constant class(es).

This assumes a central/gold DB used by all developers in order to maintain consistency. If you're using file-based storage, you can probably tie the auto-generation into your development environment. For example, you could just set a custom builder in Eclipse such that saves on a set of XML files defining your constants would trigger a script (the custom builder) that would regenerate, check out, and check in the new constant file.

Seems like a bit of work, though. Soft constants would naturally have much less overhead up front. Pick your poison :P.
AC the AC
Wednesday, February 09, 2005
 
 
If the types are known before deployment then as part of the build you can run a code generator on a configuration file that generates the classes, database load/upgrade, etc.
son of parnas
Wednesday, February 09, 2005
 
 
Putting constants will waste maintenance effort at the, I will believe there is a way to keep only code constants
Carfield Yim Send private email
Thursday, February 10, 2005
 
 
John,

Why do you need these constants in the database? Unless they are system configuration, they don't belong there.

If they are system configuration, you have to load them at startup time.
Dino
Thursday, February 10, 2005
 
 
Hi John,

I assume you are sharing these constants to something external to your Java code which is why you need them in the database?  If not, as others said, they could be a part of a property file if they are dynamic or just plain Java.

One solution to your problem would be to use the typesafe enum pattern:

http://www.javacamp.org/designPattern/enum.html

You could just serialize/deserialize your constants.  You should probably also read this tip:
http://www.javaworld.com/javaworld/javatips/jw-javatip122.html

This basically says when you are deserializing your constants to be careful not to create duplicate constants you must implement the readResolve() method.

The nice thing about typesafe enums is that it provides compile-time constant checking (as opposed to using generic Strings or ints).

Good luck,
---Tom
Tom D Send private email
Thursday, February 10, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz