我正在编写与硬件和数学相关的代码，并广泛使用无符号整数值、32 位和 64 位。如果没有任何 javac 支持，错误就会一直存在并且很难解决。 Java 8 在装箱的 Long 类上添加了一些用于除法、取模和比较的函数，但是虽然这些函数提供了运行时支持，但缺乏对两者意外混合的编译时警告，这让我很抓狂.
有人知道有什么方法可以帮助解决这些问题吗？ Java 团队成员之一提到 possible annotation support用于类型检查。
到目前为止，我为所有无符号变量添加了 u_ 前缀，甚至尝试在每次出现 int 或 long 之前添加 应该是未签名的。虽然这些很有用，但也非常困惑。这还不够远。犯错误的机会太多了。/* unsigned */ 注释
两个较大的问题是不需要的符号扩展和混合操作。
像 /* unsigned */long u_lowmask = 0xffffffff 这样无害的东西没有达到预期的结果，甚至只是 /* unsigned */long u_widen64 =small32 毁了事情用那无声的延伸。在其他语言中，我可以从编译器或类似 Lint 的静态检查器收到警告。函数式语言通常将其构建到类型检查机制中，但 Java 避开了这些，转而采用其他解决方案。混合比较或运算的机会太多了。
任何想法都希望不会对运行时产生影响，因此我无法将 unsigned 包装在类或 bignums 中。好吧，如果我可以在没有任何分配或线程局部变量的情况下完成它，我也许能够将它们包装在一个类中，但这可能会使代码不可重入。此外，Hotspot 还必须能够为接近简单 native 的包装无符号整数发出代码。 (实际上，我认为 Hotspot 可能足够聪明，可以接近 - 也许需要额外的内存读写。)
其他人是如何解决这个问题的？
最佳答案
编辑:截至 2016 年 7 月，Checker Framework 附带了您所要求的大部分或全部内容:Signedness Checker ，它验证有符号值与无符号值的使用是否一致。来自 manual :
The Signedness Checker guarantees that signed and unsigned values are not mixed together in a computation. In addition, it prohibits meaningless operations, such as division on an unsigned value.
(向@MAGx2 致敬，因为他注意到这个答案已经过时了。)
旧答案如下:
我建议您查看Checker Framework 。它使您能够定义自己的类型限定符注释，例如@Unsigned，然后在编译时检查您的代码相对于这些注释的类型是否正确。如果它没有发出警告，那么您可以保证您的代码不会混合有符号和无符号值。
Checker 框架附带 20 type-checkers ，但不适用于无符号算术。您需要write your own type-checker 。这应该相对简单，因为类型检查器需要一些特殊规则:您只是不想混合有符号和无符号值。
有关需要库注释的 JDK 方法的列表，请参阅 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71200c517524
关于java - Java 8 中处理 "unsigned"整数的想法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28032177/