Raible Designs

Matt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS

Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

TWITTER

Follow @mraible on Twitter

How do you manage your Constants?

I'm sure most of you Java Developers have a methodology for handling your "constant" values. I've seen a couple of different techniques, and I'd like to see what everyone else is doing. Currently, I use a Constants.java file that has a bunch of public final static String lines in it. I got this technique from the struts-example app when I first started working with Struts. I recently came across (can't remember where) a technique where the Constants.java file was an Interface and it was simply implemented. How are you handling this in your apps?

Secondly - do you ever use these Constants in your JSPs, or do you just use the actual values? I use the actual values - less typing.

Posted in Java at Feb 27 2003, 09:40:01 AM MST 5 Comments

Comments:

I use the same Constants.java file. I do reference values in this class from within JSPs though, so I can reference session attributes and request parameters that are keyed on names defined in the Constants.java file. eg. A key for a "user role" object would be defined in Constants.java to be: public static final String ROLE_KEY = "role"; And I reference that role by its key in the JSP like: <bean:define id="role" name="<%= Constants.ROLE_KEY %>" scope="session" type="com.simsol.util.Role"/> More typing, but makes it easier incase the actualy constant's value changes (say from "role" to "user_role") for some reason. I won't have to go back into each JSP and change it.

Posted by dsuspense on February 27, 2003 at 06:22 PM MST #

Oops: forgot the code I use the same Constants.java file. I do reference values in this class from within JSPs though, so I can reference session attributes and request parameters that are keyed on names defined in the Constants.java file. eg. A key for a "user role" object would be defined in Constants.java to be: public static final String ROLE_KEY = "role"; And I reference that role by its key in the JSP like:

<bean:define id="role" name="<%= Constants.ROLE_KEY %>" scope="session" type="com.simsol.util.Role"/>

More typing, but makes it easier incase the actualy constant's value changes (say from "role" to "user_role") for some reason. I won't have to go back into each JSP and change it.

Posted by dsuspense on February 27, 2003 at 06:23 PM MST #

Last try: <bean:define id="role" name="<%= Constants.ROLE_KEY %>" scope="session" type="com.simsol.util.Role"/>

Posted by dsuspense on February 27, 2003 at 06:25 PM MST #

You're currently following the best approach. Implementing a Constants interface is bad practice because: 1) It's not readily apparent where CONSTANT_KEY comes from, especially if the implementing class also extends a hierarchy and/or implements more interfaces than Constants. Knowing where your objects are defined at a glance is key to maintainable code. 2) Interfaces should expose an aspect of a class's behavior to clients. Even marker (empty) interfaces, which are often the tool of the devil, say something about what you can do with them, i.e. Serializable. With that said, though, it's not a bad idea to keep all those constants in a Constants interface so long as your class doesn't actually implement it... it should continue to reference them as Constants.FOO. Since interfaces can't have behaviors, keeping Constants that way enforces its intention to hold just data, not methods. As to JSPs, they should always use the constants themselves. Constants are useless if you can't change them once and affect all of their consumers.

Posted by Ryan Scharer on February 27, 2003 at 06:30 PM MST #

An interesting pattern for dealing with constants is discussed in "Effective Java" by Joshua Block. In it, he describes the typesafe enum pattern and the many benefits that arise from it. Were you to take your series of String constants and use this pattern, it would look similar to this: public class Constant { private final String const; private Constant(String const) { this.const = const; } public String toString() { return const; } // Begin actual const vals public static final Constant CONST1 = new Constant("a value"); public static final Constant CONST2 = new Constant("another value"); // ... etc ... } He goes into a detailed explanation about why this is the preferred idiom when dealing with constant classes, and makes a pretty strong case. One of the big benefits that I have personally encountered is that it allows you to pass "constant types" as method parameters. I.e.: Using our above example we could have a method with the signature doSomething(Constant c). I just found a link to this chapter: http://developer.java.sun.com/developer/Books/effectivejava/Chapter5.pdf

Posted by James Childers on February 27, 2003 at 08:11 PM MST #

Raible Designs

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

How do you manage your Constants?