在两行之间阅读时，我认为逻辑是这样的：
- 通常，Java设计人员希望简化可用数据类型的清单
- 对于日常用途，他们认为最常见的需求是签名数据类型
为了实现某些算法，有时需要无符号算术，但是将要实现这种算法的那种程序员也将具有“工作”能力，以对带符号数据类型进行无符号算术
通常，我会说这是一个合理的决定。可能，我会：将字节设置为无符号，或者至少为该数据类型提供了一个有符号/无符号的替代名称（可能具有不同的名称）（将其签名有利于一致性，但是什么时候需要一个有符号字节？）
- 删除了“短”（你上次使用16位带符号算术的时间？）
尽管如此，通过一点点混合，对不超过32位的无符号值进行的操作并不算太糟糕，并且大多数人不需要进行无符号的64位除法或比较。
