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.
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
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.
Sometimes the only way things ever got fixed is because people became uncomfortable.