JDK-4186775 : request unsigned integer types, esp. unsigned byte
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.1.7
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 1998-11-03
  • Updated: 1998-11-06
  • Resolved: 1998-11-06
Description

Name: dm26566			Date: 11/03/98


Please extend the Java design to allow unsigned types, particularly
unsigned byte.

   I have been wondering why there are no unsigned integer types in Java.  It
seems to me that for byte-length values it is extremely awkward not to have
them, for short's it is somewhat awkward, and for 32-bit int's it is simply
awkward.

  Let's focus on bytes for a minute.  What good are signed bytes?  Let's see,
maybe they could be used to record temperatures in Butte, Montana (Fahrenheit
or Centigrade!).  But what are bytes most often used for?  Let's see,
unsigned 8-bit pixels, unsigned characters that you are storing in an ascii
document, and unsigned values from 8-bit hardware registers.  I don't mean to
put Butte down, but it's really no contest.  If you _had_ to choose only
signed or unsigned, the statistically obvious choice would be unsigned.

   A similar but less compelling case could be made for short's.

   I recognize that this was a design decision made by the Java developers.
What I don't understand is why.  Did they consider unsigned integer types evil
or harmful, and chose to protect me from myself?  (That would be kind of like
Sears choosing not to sell hammers with its tool sets because they know that
some people (me especially!) would bang their thumbs.)  Or is there actually
some good reason that I don't understand?

  What I do know is that unsigned bytes and shorts have proven extremely
useful in my work with imagery (C language).  Yes, I know I can process my
images so that I cast the bytes to shorts and and with 0xff -- but when you
have tens or hundreds of millions of pixels this is a rather absurd work
around.  I don't know of a cpu that can't handle bytes naturally as unsigned
8-bit quantities (or  maybe I should say it is no more work at the assembly
language level for the cpu to use unsigned bytes or signed bytes).  I.e. the
choice in many cases is either (pseudo-assembler):

    GetUnsignedByte:
        clear    reg1              ; 32-bit register
        ldByte   reg1, (fred)      ; put the byte at address fred into reg1

or:

    GetSignedByte:
        ldByte   reg1, (fred)      ; put the byte at address fred into reg1
        sxtByte  reg1              ; echo the 7th bit thru bit 31

At this level, neither signed nor unsigned has a clear advantage or
disadvantage.  So why can't Java offer us both?
(Review ID: 41171)
======================================================================
Comments
WORK AROUND Name: dm26566 Date: 11/03/98 int biggerThanIneed = (int)(my8bitByte) & 0xff; ======================================================================
11-06-2004
PUBLIC COMMENTS he omission of unsigned integral types from Java is somewhat controversial, but they are in fact inessential, if perhaps convenient nonetheless. They are most often desired in "bit-bashing" code, such as the examples you cite. Note that in two's complement arithmetic, addition and subtraction are performed identically on both signed and unsigned quantities. That is, the signed/unsigned distinction is simply a matter of how we interpret the operands and the result, not what the operation actually does. Java provides several mechanisms to make it easy to exploit this equivalence when writing bit-bashing code: 1) Octal and hexadecimal literals specify a bit-pattern, not a positive magnitude, i.e., bit-patterns representing negative numbers may be written just the same as a bitwise-identical unsigned value would be written, and 2) both logical and arithmetic shift operations are provided. The logical shift also serves as an unsigned multiplication by a power of two, just as an arithmetic shift performs that operation for signed integers. These facilities are entirely adequate for manipulating integers as small bit-vectors, but do fall short in some cases where we are actually interested in numerical magnitudes.
10-06-2004
EVALUATION The omission of unsigned integral types from Java is somewhat controversial, but they are in fact inessential, if perhaps convenient nonetheless. They are most often desired in "bit-bashing" code, such as the examples you cite. Note that in two's complement arithmetic, addition and subtraction are performed identically on both signed and unsigned quantities. That is, the signed/unsigned distinction is simply a matter of how we interpret the operands and the result, not what the operation actually does. Java provides several mechanisms to make it easy to exploit this equivalence when writing bit-bashing code: 1) Octal and hexadecimal literals specify a bit-pattern, not a positive magnitude, i.e., bit-patterns representing negative numbers may be written just the same as a bitwise-identical unsigned value would be written, and 2) both logical and arithmetic shift operations are provided. The logical shift also serves as an unsigned multiplication by a power of two, just as an arithmetic shift performs that operation for signed integers. These facilities are entirely adequate for manipulating integers as small bit-vectors, but do fall short in some cases where we are actually interested in numerical magnitudes. william.maddox@Eng 1998-11-06 Thanks, Bill. Nicely said. In other words, it doesn't matter very much at all, so we should not destabilize the language with trivialities. gilad.bracha@eng 1998-11-06
06-11-1998