Here is the simple solution to my problem...and thank you for helping!

private static StringBuffer createCommand(char command) StringBuffer buff = new StringBuffer(); buff.append(SOM1); //A header...just a char that holds a hex value buff.append(SOM2); //Second part of header...just a char that holds.... buff.append(HEX1); //A tag buff.append(command); return buff; public static void sendMessage(String payload) StringBuffer buff = createCommand(HEX1); //HEX1 is just a char that holds 0x1; int size = payload.length(); char cLength = (char)size; buff.append(cLength); buff.append(payload); sendData(buff.toString());

So in short (no pun intended) I just stuff the size into a char and append the char to a StringBuffer at the proper position.

char cLength = (char)size;
buff.append(cLength);

Jeff Verdegan wrote:

Darrin Smith wrote:
I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

So..

0x0000 = 0
0x0001 = 1
...
0x00FE = 254
0x00FF = 255

Yes?

You can use a short for that.

On the other hand if you don't care about your Java process interpreting the bytes as the int value 255, and you just care about the bit pattern 0xFF, then simply (byte)0xFF or (byte)255 will do. Your goal still isn't clear though, so it's hard to give concrete advice.

Yes Winston, but now I have horrible memories from IBM Assembler class back in 1985 to deal with. Thanks! LOL

Winston Gutkowski wrote:

Darrin Smith wrote: I didn't spell it out well. After 20+ years of it, starting out with a Tandy Model III and working on VAX, DEC, IBM 360 and everything since, I assure you I understand how things are stored internally.

I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

Are you sure you're not thinking of packed decimal ? It's more than a decade since I've seen it, but it's the only standardized "hexadecimal" format I can think of. In the above case it would be stored as 0x255C (or 255F for unsigned), which does fit into 2 bytes.

Winston Darrin Smith wrote:
So in short (no pun intended) I just stuff the size into a char and append the char to a StringBuffer at the proper position.

This is a brittle solution, and, more to the point, using a StringBuffer for what appear to be bytes is a bad idea. Not every byte or combination of bytes is a valid char. If you have bytes rather than actual characters, don't use Stings or StringBuffers or StringBuilders at all. And if you want 2 bytes, use a short, not a char.

I thought at first you would use the % and / operators, though & and >> would work too, and might be more appropriate to the present situation. But it is obvious you want something more complicated, so I shall move this discussion.

But surely you can fit up to 255 into a single byte . All right, byte s work in two’s complement, but you can use an integer literal. Remember integer literals are implicitly unsigned, but you must cast 255 to a byte , and it can be displayed as -1. byte b = (byte)0xff; System.out.println(b); // -1 System.out.println((int)b); // -1 System.out.println(b & 0xff); // 255 You doubtless already know about right-shift by 8 places, bitwise “and” with 0xff and a cast to byte already.

Campbell Ritchie wrote:
But surely you can fit up to 255 into a single byte .

All right, byte s work in two’s complement, but you can use an integer literal.

No, we can't store 255 in a byte. If we want to interpret it as 255, we have to do some work, just as if we wanted a byte's 256 possible values to represent 1001-1256.

We can, of course, store the bit pattern 0xFF in a byte (which byte has a value of -1 in Java).

Remember integer literals are implicitly unsigned

, but you must cast 255 to a byte , and it can be displayed as -1. byte b = (byte)0xff; System.out.println(b); // -1 System.out.println((int)b); // -1 System.out.println(b & 0xff); // 255 You doubtless already know about right-shift by 8 places, bitwise “and” with 0xff and a cast to byte already.

Note that in 2rd and 3rd cases, we are printing ints. It's only in the first case that we're printing a byte.