A Funny Java Flavoured Look at the World

Monday, May 08, 2006

Constants in Java, is it right to use them?

I have recently been thinking about constants and in particular static final constants. I know it is frowned upon in the OO world but sometimes I need to put a two strings in a few places

which I have called

/** a constant value for a blank String. */
public static final String BLANK = "";
/** a constant value for a blank space String. */
public static final String BLANKSPACE = " ";

These strings are often put inbetween values in error messages, initializing some string variables etc. As I found I kept needing them in a number of classes I thought I might as well put them in a constants class and just call them from there. So I have two questions really.

1. What are the alternatives to doing this? Does Java have these constants I was looking at String and Character but I couldn't find anything.

2. Is it wrong for my classes to have a dependency on this constants class just for the a blank space and a blank.

What do other people do? Basically I just got fed up of making BLANK constants after checkstyle kept moaning at me

posted by The Hosk at 9:14 am

9 Comments:

  • Java 5 added static imports for situations like that: http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html

    In Effective Java, Bloch suggests using nonintantiable utility classes containing public static final constants - avoid the constant interface antipattern.

    Pre-Java 5, if you're tired of writing HoskyStringConstants.BLANK in a class that uses it a lot, Bloch also suggests making a private static final:

    private static final String BLANK = HoskyStringConstants.BLANK;

    By Anonymous Anonymous, at Mon May 08, 01:56:00 pm 2006  

  • thanks for your comment. Funnily enough I was reading that actual tip from Effective Java today.

    I'm not entirely sure what the best policy is really and was curious to see what other people did.

    By Blogger The Hosk, at Mon May 08, 02:39:00 pm 2006  

  • I know that a lot of people insist that it is criminal to use transcendental constants other than "0", "1", and "null". But personally, I think that they're making life more difficult with no gain.

    Constants can be particularly messy in Java because constant values are compiled into the classfiles. In Java, a constant is expected to truly be constant, never changed, ever. If you change one, you have to make sure that you track down and recompile every single Java class that uses it.

    Section 13.4.9 of the Java Language Specification (3rd Edition) says:
    "Other than for true mathematical constants, we recommend that source code make very sparing use of class variables that are declared static and final. … We also recommend, as a general rule, that only truly constant values be declared in interfaces."

    If the constant is never going to change, what is the value of giving it a separate definition? Just to make it harder to see what your code is doing?

    Personally, I would recommend that you simply use "" or " " in your Java code and don't waste your effort on making constant names for them. Besides, it just means that anyone reading the code has to go trying to track down what BLANK is defined to be. Or risk making the erroneous assumption that a BLANK is a " ".

    Further reading from my weblog (was written for the 2nd edition of the JLS).

    By Blogger Doug, at Mon May 08, 05:04:00 pm 2006  

  • Thanks for the comment Doug

    I appreciate the example I used was rather stupid and I did that so it was easy to understand but I think you oomment on constants is valid. I don't believe there should be a seperate class with constants in because firstly it does create a dependancy and secondly it just means anyone reading the code would have to hunt down the meaning.

    not to mention one persons BLANK could be "" where as another persons BLANK could be " ". so without checking it you could be in big trouble.

    I think if you are going to use a constant String you should probably just put it in the class you are using it.

    thanks for the comments

    By Blogger The Hosk, at Mon May 08, 05:55:00 pm 2006  

  • Besides that the examples you gave are not worth a constant (when would you found it useful to redefine globally ''?) - they will cause more problems are not even more readable, here a caution tale:

    As with Eclipse 3.1Mx our ClearCase plugin stopped working. I was able to fix it by just recompiling it. What happened: The plugin used some public static finals of the CVS-core which changed their values in the latest milestone. So the system ran with two values of the constants...

    With Java5 I like using enums for this, most of the time the name() method is sufficient, but this works only for simple stuff as tokens and each change requires a refactoring. When at pre 5 level I put in a safety net to protect the system from the mischief described above: The final statics get assigned by function calls, so that the literal doesn't get inlined.

    By Anonymous Anonymous, at Mon May 08, 05:59:00 pm 2006  

  • Whenever I am writing out local text files, I find myself writing

    private static final String LINEFEED = System.getProperty("line.separator");

    I do find myself wondering if that really doesn't belong somewhere other than my current class, but I've never found a good home for it.

    By Anonymous Anonymous, at Wed May 10, 01:53:00 pm 2006  

  • If you use Java 5.0, The %n code in the new Formatter class gives platform independent newlines, e.g.

    String.format("hello world!%n")

    which may obviate the need for a LINEFEED constant.

    By Anonymous Anonymous, at Wed May 10, 02:19:00 pm 2006  

  • This comment has been removed by a blog administrator.

    By Anonymous Anonymous, at Fri May 19, 08:17:00 am 2006  

  • I used to just put related constants in an Interface file and put implements Whatever in any class that needs to use them. Perhaps an abuse of the intent of interfaces, but frankly Java deserves to be abused.

    By Anonymous Anonymous, at Tue Jul 18, 04:49:00 pm 2006  

Post a Comment

<< Home