java - 在 Java 8 中处理 "unsigned"整数的想法

Question

我正在编写与硬件和数学相关的代码，并广泛使用 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 包装在类或 bignum 中。好吧，如果我可以在没有任何分配或线程本地开销的情况下完成它，我也许可以将它们包装在一个类中，但这可能会使代码不可重入。此外，Hotspot 还必须能够为接近简单 native 的包装无符号整数发出代码。 (实际上，我认为 Hotspot 可能足够聪明，可以接近 - 可能是额外的内存读写。)

其他人是如何围绕这个问题编码的？

Answer 1

编辑:截至 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，然后在编译时检查您的代码相对于这些注释的类型是否正确。如果它没有发出警告，那么您可以保证您的代码不会混合有符号和无符号值。

检查器框架附带 20 type-checkers ，但不是用于无符号算术的。你需要 write your own type-checker .这应该相对简单，因为类型检查器需要一些特殊规则:您只是不想混合有符号和无符号值。

需要库注释的 JDK 方法列表，请参见 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71200c517524