I once took a C++ course with someone on the C++ standards committee who implied that Java made the right decision to avoid having unsigned integers because (1) most programs that use unsigned integers can do just as well with signed integers and this is more natural in terms of how people think, and (2) using unsigned integers results in lots easy to create but difficult to debug issues such as integer arithmetic overflow and losing significant bits when converting between signed and unsigned types. If you mistakenly subtract 1 from 0 using signed integers it often more quickly causes your program to crash and makes it easier to find the bug than if it wraps around to 2^32 - 1, and compilers and static analysis tools and runtime checks have to assume you know what you're doing since you chose to use unsigned arithmetic. Also, negative numbers like -1 can often represent something useful, like a field being ignored/defaulted/unset while if you were using unsigned you'd have to reserve a special value like 2^32 - 1 or something similar.

Long ago, when memory was limited and processors did not automatically operate on 64 bits at once, every bit counted a lot more, so having signed vs unsigned bytes or shorts actually mattered a lot more often and was obviously the right design decision. Today just using a signed int is more than sufficient in almost all regular programming cases, and if your program really needs to use values bigger than 2^31 - 1, you often just want a long anyway. Once you're into the territory of using longs, it's even harder to come up with a reason why you really can't get by with 2^63 - 1 positive integers. Whenever we go to 128 bit processors it'll be even less of an issue.

在“C”规范中，有一些因实用主义原因而被Java抛弃的珍宝，但随着开发人员的需求(闭包等)，它们正在慢慢地回归。

我提到第一个是因为它和这个讨论有关;指针值对无符号整数算术的坚持。并且，与这个主题相关的是，在Java的Signed世界中维护Unsigned语义的困难。

我猜如果有人让Dennis Ritchie的另一个自我来建议Gosling的设计团队，他会建议给Signed's一个“无穷大的零”，这样所有的地址偏移请求都会先加上他们的algeaic RING SIZE来消除负值。

这样，向数组抛出的任何偏移量都不会生成SEGFAULT。例如，在一个封装类中，我称之为RingArray的双精度对象需要unsigned行为-在“自旋转循环”上下文中:

// ...
// Housekeeping state variable
long entrycount;     // A sequence number
int cycle;           // Number of loops cycled
int size;            // Active size of the array because size<modulus during cycle 0
int modulus;         // Maximal size of the array

// Ring state variables
private int head;   // The 'head' of the Ring
private int tail;   // The ring iterator 'cursor'
// tail may get the current cursor position
// and head gets the old tail value
// there are other semantic variations possible

// The Array state variable
double [] darray;    // The array of doubles

// somewhere in constructor
public RingArray(int modulus) {
    super();
    this.modulus = modulus;
    tail =  head =  cycle = 0;
    darray = new double[modulus];
// ...
}
// ...
double getElementAt(int offset){
    return darray[(tail+modulus+offset%modulus)%modulus];
}
//  remember, the above is treating steady-state where size==modulus
// ...

上面的RingArray永远不会从负索引中“获得”，即使恶意请求者试图这样做。记住，还有许多合法的请求用于请求先前的(负的)索引值。

注意:外层%模数去掉了对合法请求的引用，而内部%模数掩盖了明显的恶意，因为负数比-模数更负。如果这将出现在Java +..9 || 8+…+ spec，那么问题将真正成为一个“程序员不能“自我旋转”的错误”。

我相信所谓的Java unsigned int“缺陷”可以用上面的一行程序来弥补。

PS:只是为了给上面的RingArray管理提供上下文，这里有一个候选的'set'操作来匹配上面的'get'元素操作:

void addElement(long entrycount,double value){ // to be called only by the keeper of entrycount
    this.entrycount= entrycount;
    cycle = (int)entrycount/modulus;
    if(cycle==0){                       // start-up is when the ring is being populated the first time around
        size = (int)entrycount;         // during start-up, size is less than modulus so use modulo size arithmetic
        tail = (int)entrycount%size;    //  during start-up
    }
    else {
        size = modulus;
        head = tail;
        tail = (int)entrycount%modulus; //  after start-up
    }
    darray[head] = value;               //  always overwrite old tail
}

你的问题是“为什么Java不支持无符号整数”?

我对你的问题的回答是，Java希望它所有的基本类型:byte, char, short, int和long应该分别被视为字节，word, dword和qword，就像在汇编中一样，Java操作符对所有的基本类型都是有符号的操作，除了char，但只有在char上它们只能是无符号的16位。

因此静态方法对于32位和64位也是无符号操作。

您需要final类，它的静态方法可以用于无符号操作。

你可以创建这个最终类，给它起任何你想要的名字，并实现它的静态方法。

如果你不知道如何实现静态方法，那么这个链接可以帮助你。

在我看来，如果Java既不支持无符号类型，也不支持操作符重载，那么它一点也不类似于c++，所以我认为Java应该被视为与c++和C完全不同的语言。

顺便说一下，这两种语言的名称也完全不同。

所以我不建议在Java中输入类似C的代码也不建议输入类似c++的代码，因为在Java中，你将无法在c++中做你想做的事情，也就是说，代码将不会继续像c++那样，对我来说，这样的代码很糟糕，在中间改变风格。

我建议也为有符号操作编写和使用静态方法，这样就不会在代码中看到有符号和无符号操作混合使用操作符和静态方法，除非在代码中只需要有符号操作，而且只使用操作符是可以的。

此外，我建议避免使用short、int和long基元类型，分别使用word、dword和qword，并且您将调用无符号操作和/或有符号操作的静态方法，而不是使用操作符。

如果您打算只执行有符号的操作，并且只在代码中使用操作符，那么使用这些原语类型short、int和long是可以的。

实际上word, dword和qword在语言中不存在，但你可以为它们创建新类，并且它们的实现应该非常容易:

The class word holds the primitive type short only, the class dword holds the primitive type int only and the class qword holds the primitive type long only. Now all the unsigned and the signed methods as static or not as your choice, you can implement in each class, i.e. all the 16 bit operations both unsigned and signed by giving meaning names on the word class, all the 32 bit operations both unsigned and signed by giving meaning names on the dword class and all the 64 bit operations both unsigned and signed by giving meaning names on the qword class.

如果你不喜欢给每个方法取太多不同的名字，你可以在Java中使用重载，很高兴看到Java没有删除它!

如果您想要8位有符号操作的方法而不是操作符，或者想要8位无符号操作的方法而根本没有操作符，那么您可以创建Byte类(注意，第一个字母'B'是大写的，所以这不是基本类型Byte)并在该类中实现方法。

关于按值传递和按引用传递:

If I am not wrong, like in C#, primitive objects are passed by value naturally, but class objects are passed by reference naturally, so that means that objects of type Byte, word, dword and qword will be passed by reference and not by value by default. I wish Java had struct objects as C# has, so all Byte, word, dword and qword could be implemented to be struct instead of class, so by default they were passed by value and not by reference by default, like any struct object in C#, like the primitive types, are passed by value and not by reference by default, but because that Java is worse than C# and we have to deal with that, then there is only classes and interfaces, that are passed by reference and not by value by default. So if you want to pass Byte, word, dword and qword objects by value and not by reference, like any other class object in Java and also in C#, you will have to simply use the copy constructor and that's it.

这是我能想到的唯一解决办法。我只是希望我可以将原始类型类型定义为word, dword和qword，但Java既不支持typedef，也不支持using，不像c#支持using，这相当于C的typedef。

输出:

对于相同的比特序列，可以以多种方式打印它们:二进制、十进制(就像C printf中%u的含义)、八进制(就像C printf中%o的含义)、十六进制(就像C printf中%x的含义)和整数(就像C printf中%d的含义)。

请注意，C printf不知道作为参数传递给函数的变量的类型，因此printf只知道传递给函数第一个形参的char*对象中的每个变量的类型。

所以在每一个类:Byte, word, dword和qword中，你可以实现print方法并获得printf的功能，即使类的基本类型是有符号的，你仍然可以通过遵循一些涉及逻辑和移位操作的算法将其作为无符号打印到输出中。

不幸的是，我给你的链接没有显示如何实现这些打印方法，但我相信你可以谷歌的算法，你需要实现这些打印方法。

这就是我所能回答你的问题并建议你的。

在JDK8中，它确实提供了一些支持。

尽管有Gosling的担忧，但我们仍然可能看到Java对unsigned类型的完全支持。

我认为Java本身就很好，添加unsigned会使它变得复杂而没有太多好处。 即使使用简化的整数模型，大多数Java程序员也不知道基本的数字类型是如何行为的——只要阅读《Java Puzzlers》一书，就能了解您可能持有的误解。

至于实用的建议:

如果你的值是任意大小，不适合int，使用long。 如果它们不适合长期使用BigInteger。 只有在需要节省空间时，才对数组使用较小的类型。 如果你正好需要64/32/16/8位，使用long/int/short/byte，不要担心符号位，除法、比较、右移和强制转换除外。

另请参阅关于“将一个随机数生成器从C移植到Java”的回答。

字里行间，我认为逻辑是这样的:

通常，Java设计人员希望简化可用的数据类型 对于日常用途，他们认为最常见的需求是有符号的数据类型 为了实现某些算法，有时需要无符号算术，但是要实现这种算法的程序员也应该具备使用有符号数据类型进行无符号算术的知识

总的来说，我认为这是一个合理的决定。我可能会:

使字节无符号，或者至少为这一数据类型提供了有符号/无符号的替代选项，可能使用不同的名称(使它有符号有利于一致性，但什么时候需要有符号字节?) 不再使用“short”(你上次使用16位符号算术是什么时候?)

不过，只要稍加修饰，对32位以内的无符号值进行运算就不会太糟糕，而且大多数人不需要无符号64位除法或比较。