4 ms·

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 e

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 15y ago
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 15y ago
  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 15y ago
    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).
mbell 15y ago
Hardly anyone ever used Jazelle. I'm sure someone did but I don't know of a single production system using it today (maybe some legacy java based mobiles). Jazelle does not execute bytecode directly, it is not a JVM. It is a small subset of the features needed and to use it at all required a JVM written specifically for it along with specific OS support. It also required a specific licence from ARM to use. Ultimately, JIT based JVMs performed as well or better than Jazelle without the implementation specific development time or licencing costs of Jazelle. For all intents and purposes, Jazelle was a complete failure.

bri3d 15y ago

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 15y ago
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 15y ago
  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).

mbell 15y ago

Hardly anyone ever used Jazelle. I'm sure someone did but I don't know of a single production system using it today (maybe some legacy java based mobiles). Jazelle does not execute bytecode directly, it is not a JVM. It is a small subset of the features needed and to use it at all required a JVM written specifically for it along with specific OS support. It also required a specific licence from ARM to use. Ultimately, JIT based JVMs performed as well or better than Jazelle without the implementation specific development time or licencing costs of Jazelle. For all intents and purposes, Jazelle was a complete failure.