File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes String Variables/ literals Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "String Variables/ literals" Watch "String Variables/ literals" New topic

String Variables/ literals

Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
HI Ranchers,
On the same lines of thought,I was also a bit confused in declaring and using String variables for use in button text,menu text, frame title ,messages etc.
I am making constants and using these constants for this purpose,but am confused as there is going to be only one instance of GUI building classes which make use of these variables on a perticular client,so isn't it be right to just have them as private variables instead of making them constants?
Kindly comment
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11778

Hi Vikas,
Personally I prefer to have constants at the top of the class for this. It just makes it easier if you need to modify the names of the buttons later - they are all at the top of the file. You do not have to search for them.
Regards, Andrew

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
Hi Andrew,
In My implementation also i am having constants defined at the top the class for this pupose ex-
private static final String BUTTON_NAME="Submit";
But what i was asking was should i just make the above variable private instead of making it a constant?
Kindly comment
S. Ganapathy
Ranch Hand

Joined: Mar 26, 2003
Posts: 194
Hi Vakas,
Why are you creating one variable for the button label? Are you using that variable at many places? If so, better declare it as private static final constants. Compiler does some optimizations on such constants. I prefer to use like this:
(J)Button submitBut;
submitBut = new (J)Button("Submit");
But never ever declare constants in an interface. It is very bad desing, and one should avoid doing doing that.
instance variable will be created for each instance, where as class constant will be one for all instances.
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
I too would probably use a private static final variable. The private might be changed to something more public if other classes need access to the value. It's true that if the field is private, other classes won't be able to change the value (well, unless they use reflection), and so "final" may not be necessary. However (a) we may wish to protect against future changes to this class by other coders (or ourselves, after we've forgotten details of how it works); (b) saying "final" makes the field simpler to understand for everyone; especially in a multi-threaded environment we may need to think about what happens if various fields change, and seeing "final" we know we don't have to worry about it; (c) the compiler can better optimize accesses to the field in some cases if it's final.
One possible reason not to use constants for things like button labels is if you've got an internationalized application. You may wish to offer the user to change the language the GUI presents in; in this case, things like button labels will be read (and re-read and changed) from a resource bundle. So this would be a good reason not to make the button labels constant. It's not necessary for the developer cert assignment, I'm sure - but may be worth considering for similar projects in the real world.
[SG]: But never ever declare constants in an interface. It is very bad desing, and one should avoid doing doing that.
Ummm, I disagree with the "never ever" part. If the constants are intended to be part of the API, which users of an implementing class should know about and have access to, then constants in interfaces may be appropriate. E.g. consider java.util.Calendar - pretend it was an interface rather than abstract class. Here it's entirely appropriate to define a constant like Calendar.JANUARY, so that users of the class can say something like cal.set(Calanedar.MONTH, Calendar.JANUARY). I'm not going to say Calendar is a good example of API design :roll: , but the use of constants per se is not a problem.
When are constants in an interface a bad thing? It's when they're put there not because the users of the interface need the constants, but because the implementors want them. E.g. take a look at ObjectInputStream. What are all those fields inherited from ObjectStreamConstants? They're not fields that anyone using an ObjectInputStream needs to know about. They're just fields that the people who wrote ObjectInputStream (and ObjectOutputStream[/i]) wanted to talk about, and they wanted to be able to write things like
if (val == PROTOCOL_VERSION_1)
rather than
if (val == ObjectStreamConstants.PROTOCOL_VERSION_1)
so they chose to implement ObjectStreamConstants to save themselves some typing. This is a poor reason to put constants in an interface - it brings those constants into the public API of your class, when they should be a private implementation detail.
So, I agree constants in an interface are often a bad thing - but not always. Joshua Bloch complains specifically about interfaces that are designed just to export constants - but he never says that all constants in interfaces are bad. The thing to remember is, they become part of the public API of all implementing classes. If there's a reason to expect they should be part of the public API (as for Calendar) then go for it.
[ May 24, 2003: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
In many cases you will find ResourceBundle to be the right thing to use.
ResourceBundle is not for internationalization only and I use it in my implementation.
But to a certain extent it is a matter of preference.
S. Ganapathy
Ranch Hand

Joined: Mar 26, 2003
Posts: 194
Hi Jim Yingst,
I know your standard in java etc...
It is difficult for me to cross your comments many times. I forgot to mention the reference what you mentioned. Based on Effective Java Programming Language Guide by Bloch, I mentioned the comment.
java.util.Calendar is strictly an abstract class, and not an interface. Declaring only constants in an interface is bad design, it was my intention to tell. More over, we are not writing APIs to declare public constants. If we do write things like that, we should design interface very carefully.
GURU, please correct me, if I am wrong. My comment was purely based on "Joshua Bloch's" book only.
Hey man, BTW in my db file, I too found spaces instad of null string(ASCII 32 instead of ASCII 0). Sorry to merntion about it here.
Thanks n Regards,
I agree. Here's the link:
subject: String Variables/ literals
It's not a secret anymore!