

Unsigned Integer Arithmetic API in JDK 8 - bokchoi
http://blogs.oracle.com/darcy/entry/unsigned_api

======
jandrewrogers
The lack of unsigned integers as primitives in Java was a significant (and
unnecessary) defect in the design of the language. I am glad they are finally
starting to address it.

There are a number of codes and algorithms that are difficult to implement
without unsigned integer primitives. You can make the algorithms work with the
signed primitives but the implementation is nowhere near as fast or elegant as
what you can do in a language like C or C++. There are many use cases for data
types that behave like pure bit strings with no concept of sign.

~~~
MBCook
That's one thing about Java I never agreed with. I can understand the idea
that most of the time you don't really need unsigned types, but I think having
the extra checking would be nice.

The place where it's a real problem is when you have to do any low level
stuff. You read in bytes and they're all signed. So you either have to adjust
them all (such as promoting them to shorts), so change the algorithm to handle
the signs (which may make it quite a bit harder to read).

If you had to do enough, it would probably just be easier to do that stuff
with JNI, but that's quite a bit less portable and something of a hassle.

~~~
zbowling
Arithmetic aside, the byte-code is set in stone. It's even interpreted on
silicon now on ARM processors with jazella. It's going to be an incredibly
difficult effort to ever add unsigned types truly to Java without it
effectively becoming a hard fork.

~~~
bri3d
The bytecode isn't set in stone at all. Java 7 added InvokeDynamic, to name
one bytecode.

Jazelle is basically being phased out in favor of the much-more-generic
ThumbEE, which isn't onerously licensed and entirely undocumented and hence
has a chance of actually being used. New ARM CPUs "support" Jazelle by
effectively ignoring it.

It'd of course take a major-version Java release to add unsigned type
bytecodes if they chose to go that route (rather than the current approach,
which seems to be providing a dangerous and half-baked set of methods on
Integer instead). But it certainly isn't impossible by any means.

~~~
jbri
Interestingly, you don't need to add a "full set" of bytecodes for unsigned
arithmetic support - just four (udiv, ludiv, urem, lurem). All the other
arithmetic operations are bit-identical with the existing signed versions.

It's also worth noting that existing Jazelle implementations don't do
everything in hardware, they already call into a software piece to handle any
opcodes they come across that they don't interpret natively. So improving
those to handle new opcodes is just a software upgrade, same as anything else.

~~~
zbowling
The biggest issue with adding those op code is the lack of space for every op
code to support between every type IIRC. every new type exponentially
increases the number of operations. Being that we can only 255 op code in
Java, it causes a bit of a problem. In CIL/MSIL in .NET, they used a multibyte
technique with flag bits IIRC. (Don't quote me but I'm recalling designs I
seen 8 years ago here).

