aspose file tools*
The moose likes Beginning Java and the fly likes char vs String for 1 byte fields Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "char vs String for 1 byte fields" Watch "char vs String for 1 byte fields" New topic
Author

char vs String for 1 byte fields

Eak Johnson
Greenhorn

Joined: Jun 12, 2003
Posts: 1
We have JSP pages that have a lot of 1 byte fields that either have a value of 'N' or 'Y'. We have been creating Strings to hold these 1 byte fields. However when we run Optimize It, we see that some of our pages that have 40 of these 1 byte fields get pretty hefty when creating all these String objects.
My question is should we use char to hold these 1 byte fields or should we continue using Strings. What are the advantages and disadvantages.
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Off the top of my head, I would say you should switch to char. The advantages and disadvantages should be clear from what you posted already. If you are only storing a single chararacter, then the primitive char type takes up much less memory. On the other hand, the String class adds a lot of memory, and run-time, overhead. This cost buys the advantage that a String object is a bit more flexible. In particular, you can have Strings with as many characters as you wish, and different Strings can be different lengths.
I can only think of a couple of reasons to continue using the String class. First of all, if you forsee any of these fields possibly holding more than a single character some time in the future, then String will make it easy to do this. Second, JSP may have some differences, that I am unaware of, between char and String. However, I suspect that this later issue isn't nearly as important as the first.
In short, if you are sure that these fields will always be a single byte, my opinion is to use char instead of String.
HTH
Layne


Java API Documentation
The Java Tutorial
peter greaves
Ranch Hand

Joined: Sep 27, 2002
Posts: 51
aren't your "Y" or "N" replies just 0 or 1s? iwc why not for storage and manipulation have an array of (say) 128 bytes, and use the pattern in the bytes to determine the replies? the fact that the user might have Yes or No in the UI does not mean that the business logic has to deal with it in that way? when the page is submitted, you could use JavaScript to concat all the Y or Ns to a String which represents the sequence e.g "0001001001" etc and then use getBytes to get the byte sequence. so then you would have one String for all the replies. you could have to figure out the rel. between the order in the bytes array and the N or Y but that might not be hard.
hope this helps
peter


SJCP 1.2
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Why use a String at all? It sounds like you are creating objects that you don't need. Perhaps a boolean would be a more natural way to hold a "yes"/"no" answer.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16061
    
  21

First, I'm going to have to be picky and point out that bytes and characters are not the same thing. A Unicode character is 2bytes long.
I normally would prefer to keep entities in their own proper datatypes, which means that I'd go with "boolean". However JSPs are character-oriented and you'd pay a fairly high penalty since the data has to be converted coming in and going out (I'm assuming this is data on the JSP and not in something like a session object) and that data is already in String objects, so you'd be adding both computational and storage overhead.
Incidentally, back in my mainframe days, I used to work a lot with boolean data in S/370 assembly language. One day I realized that for cases where the bitswitches were unique (as opposed to being part of each of 50,000 records), the storage overhead of the bit-access instructions was more than the storage saved by packing bits, and the number of CPU cycles required to set and get bits was likewise higher than if I'd simply used a byte to store an EBCIDIC character with a Y or N. Also, it was easier to read out the switch values from a core dump.
What goes around comes around, I guess. I'd try arrays of boolean or character items if you don't have the "value already exists as String" problem I mentioned earlier.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: char vs String for 1 byte fields