• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

char vs String for 1 byte fields

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 25653
183
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic