The (short) casts are unnecessary unless `x' is a float
or a double.  Also, you can get rid of the masks and just
rely on the (byte) casts:

    buffer[index++] = (byte)(x >> 8);
    buffer[index++] = (byte)x;

... but you'll probably need to do this to quite a large
number of values before you see a measurable speed change.

    You're working too hard.  Try

    short x = (short)(buffer[index++] << 8);
    x += buffer[index++] & 0xFF;

You could even pack all of this into one statement like

    short x = (short)((buffer[index++] << 8)
                     + (buffer[index++] & 0xFF));

... but this is cringe-inducing to old C programmers
like me.  (Even though javac knows how to organize the
side-effects, there's no point in giving the maintenance
programmer a chance to make a "harmless" rearrangement.)

    Maybe, maybe not, and maybe the answer is different on
different systems.  How much will you suffer if it turns
out to be only the second- or third-most efficient?

    So do I.  I also find it annoying that mosquitoes bite,
but I learn to get along anyhow.

    As far as I can tell, both the originals and the rewrites
should work for all values.  But since there are only 65536
short values, you could easily write a little test program
to pack and unpack all of them and report any discrepancies.

Have you looked into using a ByteBuffer?
<http://java.sun.com/j2se/1.5.0/docs/api/java/nio/ByteBuffer.html>
It has putInt, putLong, putShort, putChar, putDouble, etc....

You can use ByteBuffer.wrap(bufferArray) too.

HTH.

Have you considered using ByteBuffer? It is designed to do exactly this kind of
thing. Whether it is more efficient is another matter entirely, but it ought to
be simpler and your intention should be more transparent.

You can use a DataOutputStream to a ByteArrayStream.  Sun is going to
write pretty good code.  You can also peek at how Sun does it by
looking up the code in src.zip or letting your IDE find it for you.

I have similar code in LEDataStream doing the same thing for little
endian binary data.

See http://mindprod.com/products.html#LEDATASTREAM

Efficiency is in the eyes of the beholder - the code you've written is very
efficient in terms of economy of memory usage, but fails to be efficient when
the code needs to be maintained, as it is relatively difficult to deduce the
purpose of stuffing these three values into one.  This loss of efficiency may
end up costing you more in the long run - what happens when a junior coder is
tasked with adding a fourth value into the composed collection of values.

If your purpose is to return three values as one from a method call, then I
would recommend that you create a small private inner class that contains
each of the three individual values that you need to return as instance
fields, and that you return an object of this class instead of performing
these gymnastics.

Cheers!
GRB