9

There are questions about why Java doesn't support unsigned types and a few questions about dealing with unsigned types. I did some searching, and it appears that Scala also doesn't support unsigned data types. Is the limition in the language design of Java and Scala, in the generated bytecode, or is it in the JVM itself? Could there be some language that runs on the JVM and is otherwise identical to Java (or Scala), yet supports unsigned primitive data types?

Community
  • 1
  • 1
Thomas Owens
  • 114,398
  • 98
  • 311
  • 431

4 Answers4

9

Java Bytecode Specification only defines signed types:

The integral types are byte, short, int, and long, whose values are 8-bit, 16-bit, 32-bit, and 64-bit signed two's-complement integers

But a language implemented on top of the JVM can probably add an unsigned type at the syntactic level and just handle the conversion at the compilation stage.

Dmitry B.
  • 9,107
  • 3
  • 43
  • 64
  • I never even thought to look in the bytecode spec. I should have. I only looked at the Java Language Specification and various Scala documentation. – Thomas Owens Dec 01 '11 at 17:39
  • "The built-in integer operators do not indicate (positive or negative) overflow in any way; they wrap around on overflow." That would also indicate that if you handle the cases properly, you can indeed implement unsigned data types using the standard arithmatic operators. – Thomas Owens Dec 01 '11 at 17:41
  • Back in the day I used to work with the QuckTime Java api that's just a wrapper around the native QuickTime library that, if my memory serves me right, was full of unsinged integer types. It was somewhat awkward api-wise, but the signed-unsigned conversion worked ok. – Dmitry B. Dec 01 '11 at 17:57
  • Java's non-extending shift operator `>>>` corresponds to C's `>>` on unsigned types. It is implemented via the bytecode instruction `iushr` for 32b wide values and `lushr` for 64b wide values. The 'u' in those instruction names stands for "unsigned". – Mike Samuel Jan 12 '12 at 19:53
2

Although unsigned type might be emulated at the bytecode level there are some drawbacks with that:

  • Performance: You would need several bytecode operations for each simple arithmetic operation. The performance of code using the emulated unsigned types would be two or three times worse than code using signed types.

  • Compatibility: Most languages running on a JVM try very hard to be compatible with the huge amount of Java code out there. This of course would be spoiled immediately when additional types are introduced or when some variables with "known" types have to handled differently.

In the light of this the benefits for unsigned types are IMHO negligible.

A.H.
  • 63,967
  • 15
  • 92
  • 126
  • Additions and subtractions of like-sized numbers would not be affected. Comparisons would probably be the biggest nuisance. – supercat Apr 25 '14 at 22:09
  • @supercat: why do you think so? – A.H. Apr 26 '14 at 07:26
  • 1
    The only operations I can think of that would be affected would be division, comparisons, and conversions to `long` or floating-point types. Of those, comparisons would be used more frequently than the others, and would normally take the least amount of time. – supercat Apr 26 '14 at 17:58
  • 2
    The benefits of unsigned types are not negligible. There are all sorts of gymnastics that need to be done to support fixed point numerics and systems programming interoperability on the JVM. – ctpenrose Jul 25 '18 at 06:53
0

Eta has support for unsigned types on the JVM.

Colin Woodbury
  • 1,799
  • 2
  • 15
  • 25
0

Handling unsigned arithmetic is a language/implementation issue, not platform--it could be simulated on any platform even if there was no native support.

The JVM doesn't have it as a type, except for 'char', an unsigned 16-bit value, so Java/Scala/etc. don't support it "out of the box".

Dave Newton
  • 158,873
  • 26
  • 254
  • 302