wood burning stoves 2.0*
The moose likes Servlets and the fly likes Including Utility Function & Constants in Servlets Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Including Utility Function & Constants in Servlets" Watch "Including Utility Function & Constants in Servlets" New topic
Author

Including Utility Function & Constants in Servlets

Merrill Cornish
Greenhorn

Joined: Jan 20, 2004
Posts: 4
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
Billybob Marshall
Ranch Hand

Joined: Jan 27, 2004
Posts: 202
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.
Merrill Cornish
Greenhorn

Joined: Jan 20, 2004
Posts: 4
Thanks. And yes, I should have thought about the private constructor.

Merrill
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.


    Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
    Kyle Brown
    author
    Ranch Hand

    Joined: Aug 10, 2001
    Posts: 3892
        
        5
    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


    Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
    See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Including Utility Function & Constants in Servlets
     
    Similar Threads
    Class or Interface
    JSP calling a method
    Designing JSPs
    use diffrent servlet values (how to unload a servlet)
    JSP calls Servlet calls JSP