【问题标题】:Why does the Boolean object have a public constructor in Java?为什么布尔对象在 Java 中有一个公共构造函数?
【发布时间】:2011-11-18 01:03:56
【问题描述】:

Java 中构造函数new Boolean(boolean value) 的文档说明:

注意:很少使用这个构造函数。除非需要新实例,否则静态工厂valueOf(boolean) 通常是更好的选择。它可能会产生明显更好的空间和时间性能。

如果是这样,为什么这个构造函数是公开的并且不被弃用?是否有充分的理由使用此构造函数而不是 Boolean.valueOf()

【问题讨论】:

标签: java boolean


【解决方案1】:

valueOf() 仅在 Java 1.4 中添加,因此构造函数的存在似乎是为了向后兼容。

This ticket 解释了不弃用构造函数的原因:

由于弃用 API 可能造成的中断,目前的 API 必须是“积极危险”才能被弃用,例如 Thread.stop。 虽然使用这个构造函数肯定是不明智的,但它并没有 上升(或下降)到要弃用的危险性标准 JDK。将来我们可能会添加一个“诋毁”设施来标记 API 元素还不错,应该被弃用, 但在大多数情况下不应使用。这个构造函数会很好 诋毁候选人。

我想不出一个现实的场景,使用 Boolean 构造函数将是做一些有用的事情的最佳方式。

【讨论】:

  • 也许需要注释 @discouraged 或其他东西来表明它不是非常危险的,但实际上并没有充分的理由这样做。
  • 如果想拥有一个也可以封装位标志的锁令牌怎么办?可以为此编写自定义类型,但 Boolean 已经存在。
  • @supercat 我想说AtomicBoolean 可能是一个更好的选择。或者Semaphore,虽然这对于一个简单的标志来说可能太花哨了。
  • 需要正确解释为什么这是不好的。每个人似乎都在重复鹦鹉式的做法,认为它不好,但很少有信息说明为什么 valueOf 更好,以及为什么 Oracle/Sun 微系统不只是从其构造函数内部调用 valueOf 而不会影响开发人员。
【解决方案2】:

通常,您会想要直接使用valueOf(boolean) 甚至Boolean.TRUE / Boolean.FALSE 常量。

但是考虑一个场景,您希望使用私有Boolean 变量作为同步线程的监视器。在那里,您需要确保使用自己的实例并完全控制它。

【讨论】:

  • 这是一个非常不重​​要的原因;实际上还有成千上万的其他对象可以用作监视器。我不认为将 Boolean 保留在该集合中是高优先级。
  • 不重要但很好的用例,valueof 方法可能会返回重复的对象,有时你不希望这样
  • @Costi new Boolean(boolean value)ValueOf(boolean) 的意义在于你有一个 boolean 并且需要一个 Boolean 来使用你需要使用的常量 `b ? Boolean.TRUE:Boolean.FALSE。这比前两种方法好多少?
  • @Hemal, "new" 创建一个新实例。由于布尔值是不可变的,因此通常会浪费一个对象 - valueOf() 返回两个对象 Boolean.TRUE 或 Boolean.FALSE 之一。使用 Boolean.TRUE/FALSE 比 valueOf() 更快,因为 true 或 false 的选择是在编译时完成的。当然,如果你直到运行时才知道它是哪个,那么与 valueOf() 相比没有任何优势。
  • @Ed,好的,我同意new 不是一个好主意。我也同意Boolean.TRUEBoolean.valueOf(true) 更可取,但这不是讨论的重点。
【解决方案3】:

另一个不一定很好的理由可能是简单地保持它与其他本机包装器的一致。

【讨论】:

  • 有信心!这是一个相当不错的理由。
  • 我主要是怀疑 Java 的创造者,而不是我自己 :)
【解决方案4】:

从 Java 9 开始,Boolean(boolean) 构造函数已被弃用;见javadoc

对于那些关心历史的人来说,有一个长期存在的bug 呼吁弃用构造函数。它是在JEP 277 中正式提出的,同时还有一些其他弃用。

【讨论】:

    【解决方案5】:

    它没有被弃用的原因是 Java 保持向后兼容 1.0 版

    我想不出使用构造函数的好理由。

    【讨论】:

    • 将其标记为弃用不会阻止它向后兼容。实际上,这就是它的全部意义所在。
    • Java 不保持与 1.0 版的向后兼容性:几个 JDK(我想不到,1.4 和 1.7)引入了无法在早期 JRE 上运行的构造。他们只是非常不愿意破坏任何东西,并认为这个糟糕的构造函数还不够危险来保证破坏向后兼容性。
    • @amalloy 那将是前向兼容性;向后兼容性保证了可在早期 JRE 上运行的构造可以在以后的 JRE 上运行(这也是 Java 泛型通过类型擦除实现且原始类型仍然存在的原因之一)。
    猜你喜欢
    • 2020-03-22
    • 1970-01-01
    • 1970-01-01
    • 2012-01-20
    • 1970-01-01
    • 2011-10-23
    • 1970-01-01
    • 1970-01-01
    • 2012-03-12
    相关资源
    最近更新 更多