Hi ,
In my appilcations we are using literals directly in our classes rather than declaring those as contants in a separate constants file and then using them? So my question is whts the correct way of doing it? Should I use the literals directly or use a constants file for it? I am more concerned for the performace at run time of mt application. Also please tell me wht effect does it have in maintainance.
> In my appilcations we are using literals directly in
> our classes rather than declaring those as contants
> in a separate constants file and then using them?
How would I know? It's your program. :)
> So
> my question is whts the correct way of doing it?
Put the String texts into a Properties file.
> Should I use the literals directly or use a constants
> file for it?
The latter.
> I am more concerned for the performace
> at run time of mt application.
How so?
> Also please tell me
> wht effect does it have in maintainance.
A good one. Think about what you have to do if a user complains about a typo in some message. You'll have to scan all of your source files to find it. The other way there's just one file to look at. And think what you'd have to do if your program is supposed to use a different language.
It depends on the "constants". Some constants are more constant than others. Also some constants naturally fall into a particular class, and are best declared there.
Configuration stuff, like file paths, URLs etc. etc. I always prefer to put in a config file, either a .properties or, for more complex applications, an XML file.
Display strings you should consider the possibility that your application may need to be "internationalized", if so then thay should be put in resource bundles.
I don't care for "Constants.java" myself. Stuff like resoruce bundles, properites files etc. get loaded only once so there are not big time overheads.
The only snag, I find, is the danger of misspelling resource keys, either in the code or in the resource file itself because these mappings can't be checked at compile time.
> What my view was for the first time the constants
> file would be compiled and then used throughout the
> appilcation ?
The file won't be compiled at all.
> But in literals they would be directly
> used? So are LIteral usage faster?
Run a test, and then tell us whether your sytem's timer was actualy able to measure the difference. Believe it or not, performance is not your problem here. Other aspects are much much more important.
> > The only snag, I find, is the danger of
> misspelling
> > resource keys, either in the code or in the
> resource
> > file itself because these mappings can't be
> checked
> > at compile time.
>
> You can still introduce constants for those.
Yes, in one project I wrote a little program that read a properties file and autmatically generated a Java class associating a name with each key.
You still have to ensure you run it, of course.
> But my major concern is about the performace of the
> application:) so which one is faster?
Reading values from a file will be slower than compiling literals into your code. If you read the file every time you use the value, this could have a significant performance impact. If the value is constant, though, you wouldn't do this. You'd just read the file once at startup. Compared to the real work that your program is doing, reading and parsing a text file of a few dozen or even a few thousand lines will almost certainly be insignificant.
> So does that mean at run time there will not be any
> difference?
Only if you consider 0.00002 seconds or however a difference. And you could still have a single class for those literals and refer to them there if you want to save the 4 milliseconds it takes to load the file during 20 seconds of program startup. That way you still have them in one place, and no performance "loss".
> > So does that mean at run time there will not be
> any
> > difference?
>
> Only if you consider 0.00002 seconds or however a
> difference. And you could still have a single class
> for those literals and refer to them there if you
> want to save the 4 milliseconds it takes to load the
> file during 20 seconds of program startup. That way
> you still have them in one place, and no performance
> "loss".
And make sure to keep all class and method names to one letter, so the class files will load faster.
The project I was on until recently had a Constants class. It was used to store all sorts of unrelated constants. The names were badly chosen (Constants.One meant something different--and was a different type--from Constants.ONE; same for Constants.Yes/Constants.YES, etc.). There were a few other classes that were all constants, but most constants just ended up in the one class. So, that class was an overgrown mishmash of stuff.
So, if you want constants, I'd suggest a few things:
1. Don't put all the constants for the whole application in one class. Split it up into multiple classes according to use. Could be by package. Or, just at the top of the class that uses them, if they aren't used in more than one class.
2. Use meaningful names (this is always a recommendation for variable names and method names).
3. If you have one or more classes with constants, use the constants consistently. A typo in a literal String (instead of using the constant String) will cause your code not to work, and it won't be found at compile time. Depending on your test thoroughness, the bug may lie dormant for years.
4. Don't use constants for everything. Some people on the project made me make a constant for the 1000 in the following:
List myList = new ArrayList(1000);
That kind of constant is going overboard, IMO--it is just an initial size of the underlying array for the list. Constants for some Strings needed from the XML that we had made sense, but a constant for that 1000 is ridiculous.
