java - 原始包装类(整数、 double 等)和字符串可以近似为基于值的类吗？

Question

Java介绍value based Java 8 的类，并且只用它标记了几个 Java.Util(可选)和 Java.time 类。
基于值的类的标准定义为 here .
这些标准中的大多数(除了在身份敏感操作中使用它们的严格指导以及它们不应该具有可访问的构造函数的事实)似乎适合原始包装类，如 Integer、Double(以及类似的不可变类，如 String)。我知道从技术上讲，开发人员可能已经将这些类与基于身份的操作一起使用(尽管他们不应该使用)，因此将它们标记为 value based现在可能会导致向后兼容性问题。但除此之外，还有什么其他原因可以概念 ，这些包装类不是基于值的吗？
我倾向于将它们视为基于值(value)的原因。
当您定义 Integer myInt = 5 ，您实际上只对值 5 感兴趣，而不是对持有该值的引用感兴趣(至少对于我能想到的大多数用例)。同样当你说 String myStr = "hello world" ，你真的对值(value)文字“hello world”感兴趣，而不是它的引用。

Answer 1

基本上，您指出了最重要的原因，即为什么将这些类改造为基于值的类是不可行的:向后兼容性。
您可能已经注意到原始包装类型的构造函数在 Java 9 中已被弃用，这将是朝着这个方向迈出的一步。尽管如此，仅不鼓励而不是禁止使用身份敏感操作，因此不能在此基础上进行破坏兼容性的更改。但是可能会破坏身份敏感操作，这将是唯一可以使后续的实际优势成为基于值的类的事情。
对于像 String 这样的类(class), BigInteger , 和 BigDecimal , JDK 开发者甚至不敢采取弃用构造函数的步骤，很可能是因为那太破坏性了。对于某些构造函数，甚至没有等效的工厂方法。
但不仅仅是公共(public)构造函数。
请参阅 valueOf 的文档方法，the one of Integer 示范:

This method will always cache values in the range -128 to 127, inclusive, …

因此，当使用工厂方法时，您仍然会在某些情况下获得指定的身份行为。
这将我们带到 JLS §5.1.7 :

If the value p being boxed is the result of evaluating a constant expression (§15.29) of type boolean, byte, char, short, int, or long, and the result is true, false, a character in the range '\u0000' to '\u007f' inclusive, or an integer in the range -128 to 127 inclusive, then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

因此，即使是语言也指定了某些身份敏感操作的行为。
请注意，规范尽量不将 valueOf 命名为编译代码将在实践中使用的方法，但要制定自己的规则(正式仅适用于编译时常量)，这并没有真正得到返回。如 this answer文档，规范的那部分经历了几次重写，所以当任何人从字面上理解措辞时，保证随着时间的推移而改变......
其他保证已经深入开发人员的脑海:
JLS §15.29, Constant Expressions :

Constant expressions of type String are always "interned" so as to share unique instances, using the method String.intern.

这是对无法拒绝的对象身份的保证。
有趣的是， JLS §15.18.1状态:

The String object is newly created (§12.5) unless the expression is a constant expression (§15.29).

目前尚不清楚这种严格的措辞是否是故意的，但正如所写的那样，它指出对于非常量字符串连接，它必须产生一个具有不同标识的新对象。开发人员不应依赖的另一种指定行为。
因此，如果有人要设计一种没有遗留的新语言，那么首先将这些类型设计为值类型并没有错。设计师只需要避免将所有这些保证放入过去被认为是一个好主意的规范中。