Including Utility Function & Constants in Servlets
Joined: Jan 20, 2004
I have a problem and I have ONE solution to that problem; but I'm wondering if it's the best choice. I have a set of servlets and JSP pages for my Tomcat application. I have a general need for a set of utility functions and constants (some ilntegers, but mostly strings) to be shared by all of the servlets and pages. Under C or C++, this problem would result in a utility library and a header file; but Java doesn't quite work like that. So... Along with my servlet classes, I have defined a public class named Util composed exclusively of public static (and in the case of data values, final) data and functions. Therefore, in each of my servlet files and JSP pages, I import the Util class. Since everything is static, I don't have to actually instantiate Util, instead, I can simply code things like Util.TIMESHEET_PAGE_URL (for a string constant) or Util.banner("page banner name"); (for a function). As I said, this all works, but I was wondering if there is a different convention I should be following. Merrill
Joined: Jan 27, 2004
Originally posted by Merrill Cornish: I have a problem and I have ONE solution to that problem; but I'm wondering if it's the best choice.
Yes, that's the convention. Also create a private no-arg constructor for that Util class so noone can superfluously create an instance of Util.
Joined: Jan 20, 2004
Thanks. And yes, I should have thought about the private constructor.
Joined: Jan 07, 1999
This is a reasonable solution if:
your set of "utilities" is small
you need all the utilities in every application that needs any of them
you will never need to change the behaviour or values of your "utilties" at "run" time or when the application is deployed.
If some or all of the above are not true, you may want to consider alternative idioms. If your set of utility values and methods is large, or growing, or some uses don't need all of them, you should consiser splitting your "Util" class into smaller, more task-specific utility classes. For example, I once had such a single-class-collection which included such diverse things as date calculations, number parsing, and XML output. By splitting them into different classes I was able to increase their reusability and reduce the deployed size of several applications. Also, please think clearly about names for things. While "Util" may seem reasonable now, it probably won;t be very obvious in six months time what methods and value are likely to be in there. Often splitting into smaller, more specific classes helps readability too. I'd guess that ProductCreationUtilities (for example) might give more of a hint than just "Util". If some of your utility methods are application-specific, or may need to be configured differently for different applications, consider creating an object instance of such a "utility" class when the application starts up, storing it in the "application context" (provided to all servlets and JSPs), and retrieving it from the context when needed. This decouples the code which uses these "utilities" from the specific implementation class.
This approach can even allow the name of the utility class to be an "init parameter", prividing complete deploy-time flexibility.
Frank's approach is a good one. Another common approach for constants at least is to place all of your constants within an Interface specifically built for that purpose. This is used quite often within the Java class libraries, for instance. Kyle