Java 包装器类型除了性能之外还有什么缺点吗？

在我的工作领域中，我主要从事具有大量数据库代码的业务应用程序。我通常不写数字运算的科学逻辑

这让我想知道——在实体类中始终使用包装器类型是一个好主意吗？我发现自己经常将原语转换为包装器。相反，我想不出有哪种情况下，我不能没有原语

如果我将实体中的字段声明为包装器，则从db读取的数据将由我的持久性层自动映射到这些字段上，从而省去了手动创建这些字段的麻烦

有些事情只能通过经验来实现，所以我问你们，有人尝试过这种方法吗？有什么问题吗

我并不关心性能，但我是从良好实践/架构的角度提出这个问题的。

包装器与原语

专业人士

• 可以与泛型一起使用
• 支持许多其他方法

缺点

• 使用更多的cpu
• 使用更多内存
• 表示该值可以是

  null

• 在某些情况下，打印时间较长

---

由于cpu和内存与我无关，而且db值可能明显为空，因此我想这是对all wrappers方法的一种肯定。是吗？如果它可以是

null

，那么使用包装器可能是更好的选择。我更喜欢在可能的情况下使用原语，但不是在这种情况下。顺便说一句，我关于较长名称的观点似乎无关紧要，除了编写

整数

而不是

int

所需的时间可能比内存差异的成本高出1000倍。然而，编写令人困惑的代码的成本通常要高得多，所以尽可能简单明了。谢谢。我问这个问题的原因是Ruby没有原语，只有包装器。我希望java能有更短的名称。理想情况下，编译器可以优化原语与包装器的使用，这样你就不必担心了。我会添加一个关键字或注释，说明一个值是否可以

null

。（默认情况下，我会使变量不

null

可启用）