I'm looking into resolving a problem I'm facing with streams, bytes, byte arrays. I would like to hear your opinion on the best practice to implement what I want.
So the story follows.
I've created a series of classes, with property accessors, and some internal behavior.
What I intend to reach is a class that developers can instantiate, define some parameters through specific setter methods, and then put some data to be processed (passed in as byte). All that will be wrapped in this nice little class, and then I'll have a major process that picks that class, and do some processing. Based on the data stored and properties defined by setter methods, the processing will end up returning a byte array (byte).
Nice. I can now save it to disk ... nice.
Then I have the opposite process ... a parser that receives an InputStream and just flies through it, and at the end returns a properly instantiated class, so application code can use it accordingly. I'm thinking InputStream, because that way I could just feed the processing with almost any sort of source ... file, byte array in memory, socket received stream data ...
All was going well until I found this small problem ... byte is signed in java ... which means that if I pick "11011111" binary, convert into 223 decimal, and then store it into a byte, it will end up being -33.
Well, I can correct this behavior with some arithmetic logic, in the form of:
That would do the trick, but that just don't gives me comfort about the way I'm doing this, and would require this step of conversion after receiving the byte array. There are some bytes that are created bit-by-bit, so I can get any byte from 0-255 interval.
What would be a good way to do this? Should I work with byte data for storing data, retrieving, and so on, as I'm doing now?
Should I just work with Strings?
Should I go with int and store decimal representations?
The byte array seemed to me more low level, and so with more performance and better versatility ... as for instance even the String has a constructor that receives a byte, and System.arraycopy could be used for some special work over the processed data.
I'm not really seeing the problem here. Whether Java considers a byte to be signed or unsigned doesn't change the fact that it contains the bit pattern 11011111. The only impacts would be:
1. If you cast the value to a larger integer type, the sign bit would be extended to the higher order bits. Workaround: 0 out the higher order bits.
2. If you converted the byte to a String, it would display as a negative number. Workaround: cast the byte to a higher order integer and 0 out the higher order bits.
3. If you compared one byte value to another, e.g., using the less-than operator, the results could be different than if you compared unsigned values. Workaround: yeah, that cast and 0 thing again.
However, you can do an awful lot of processing on a byte array without ever running across one of these cases. What is it that you need to do that is disrupted by having signed values?
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop