blocks|key|2936946|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2936947|为什么它还没有被弃用？|blockquote|2936948|2936949|2936950|因为JCP认为不适合这样做，而且可能永远不会这样做。问问他们。你问错地方了。|2936951|2936952|将其保留在Java+API中的原因是什么|2936953|2936954|2936955|没有人会从Java+API中删除任何东西，因为需要向后兼容。上一次发生这种情况是在1996/7年，AWT事件模型在1.0和1.1之间进行了更改。|2936956|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|R|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|T|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|U|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|W|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|Z|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|10|7|@]|8|@]|9|$]]]|P|$]]

<blockquote>
 why it is not deprecated yet?
</blockquote>

Because the JCP hasn't seen fit to do so, and may never do so. Ask them. You're asking in the wrong place.

<blockquote>
 What are the reasons behind keeping this thing in Java API
</blockquote>

No-one will ever remove anything from the Java API, because of the backwards compatibility requirement. The last time that happened was the change in the AWT event model between 1.0 and 1.1 in 1996/7.

blocks|key|148684|text|1997年向Java+Bug+Database提交了一份关于将clone()方法添加到Cloneable的bug，因此它不再是无用的。它是以“with‘t+fix”解决方案关闭的，理由如下：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|148685|148686|太阳公司的技术审查委员会详细考虑了这个问题，并建议除了改进当前可克隆接口的文档之外，不要采取任何行动。以下是该建议的全文：|blockquote|148687|148688|现有的Java对象克隆API存在问题。在java.lang.Object上有一个受保护的“克隆”方法，并且有一个接口java.lang.Cloneable。其意图是，如果一个类想要允许其他人克隆它，那么它应该支持Cloneable接口，并用一个公共的clone方法覆盖默认的受保护的clone方法。不幸的是，由于时间的原因，Cloneable接口并没有定义clone方法。|148689|这种组合导致了相当大的混乱。一些类声称支持Cloneable，但却意外忘记了支持clone方法。开发人员对Cloneable应该如何工作以及克隆应该做什么感到困惑。|148690|不幸的是，向Cloneable添加"clone“方法将是一个不兼容的更改。它不会破坏二进制兼容性，但会破坏源代码兼容性。轶事证据表明，在实践中，有许多情况下，类支持Cloneable接口，但未能提供公共克隆方法。经过讨论，TRC一致建议我们不应该修改现有的可克隆接口，因为这会影响兼容性。|148691|另一个建议是添加一个新的接口java.lang.PubliclyCloneable，以反映Cloneable最初的预期目的。以5比2的多数，TRC建议反对这一点。主要的担心是这会增加更多的混乱(包括拼写混乱！)一幅本已混乱的图景。|148692|TRC一致建议我们应该向现有的可克隆接口添加额外的文档，以便更好地描述如何使用它，并为实现者描述“最佳实践”。|BOLD|148693|148694|因此，尽管这不是直接关于弃用的，但不使可克隆的“弃用”的原因是技术审查委员会认为，修改现有文档的将足以使该接口有用的。他们就是这么做的。在Java1.4之前，Cloneable的文档如下所示：|148695|Cloneable类实现Cloneable接口，以向Object.clone()方法指示该方法对该类的实例进行字段对字段复制是合法的。|148696|尝试克隆未实现Cloneable接口的实例会导致抛出异常CloneNotSupportedException。|148697|Cloneable接口没有声明任何方法。|148698|148699|从Java1.4(2002年2月发布)到当前版本(Java8)，它看起来是这样的：|148700|Cloneable类实现Cloneable接口，以向Object.clone()方法指示该方法对该类的实例进行字段对字段复制是合法的。在没有实现Cloneable接口的实例上调用对象的克隆方法会导致抛出异常CloneNotSupportedException。|148701|按照约定，实现此接口的类应使用公共方法重写Object.clone+(受保护的)。有关覆盖此方法的详细信息，请参阅Object.clone()。|148702|请注意，此接口不包含clone方法。因此，仅仅因为对象实现了该接口，就不可能克隆该对象。即使以反射方式调用克隆方法，也不能保证它会成功。|148703|entityMap|0|LINK|mutability|MUTABLE|url|http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4098033|1^0|V|7|17|9|6|H|0|1H|3|1|0|0|0|0|0|0|0|0|0|K|0|0|1C|A|27|9|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1M|8|@$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@$9|1R|A|1S|1|1T]|$9|1U|A|1V|1|1W]]|E|$]]|$1|F|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1Y|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|20|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|21|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|22|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|23|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|24|8|@$9|25|A|26|B|U]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|27|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|28|8|@$9|29|A|2A|B|U]|$9|2B|A|2C|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|2D|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|2E|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|2F|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|2G|8|@]|D|@]|E|$]]|$1|15|3|16|5|6|7|2H|8|@]|D|@]|E|$]]|$1|17|3|18|5|6|7|2I|8|@]|D|@]|E|$]]|$1|19|3|1A|5|6|7|2J|8|@]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|2K|8|@]|D|@]|E|$]]|$1|1D|3|-4|5|6|7|2L|8|@]|D|@]|E|$]]]|1E|$1F|$5|1G|1H|1I|E|$1J|1K]]|1L|$5|1G|1H|1I|E|$1J|1K]]]]

There is a <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4098033">bug</a> submitted in 1997 to <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4098033">Java Bug Database</a> about adding <code>clone()</code> method to <code>Cloneable</code>, so it would no longer be useless. It was closed with resolution "won't fix" and justification was as follows:

<blockquote>
 Sun's Technical Review Committee (TRC) considered this issue at length
 and recommended against taking any action other than improving the
 documentation of the current Cloneable interface. Here is the full
 text of the recommendation:
 
 The existing Java object cloning APIs are problematic. There is a
 protected "clone" method on java.lang.Object and there is an interface
 java.lang.Cloneable. The intention is that if a class wants to allow
 other people to clone it, then it should support the Cloneable
 interface and override the default protected clone method with a
 public clone method. Unfortunately, for reasons conveniently lost in
 the mists of time, the Cloneable interface does not define a clone
 method.
 
 This combination results in a fair amount of confusion. Some classes
 claim to support Cloneable, but accidentally forget to support the
 clone method. Developers are confused about how Cloneable is supposed
 to work and what clone is supposed to do.
 
 Unfortunately, adding a "clone" method to Cloneable would be an
 incompatible change. It won't break binary compatibility, but it will
 break source compatibility. Anecdotal evidence suggests that in
 practice there are a number of cases where classes support the
 Cloneable interface but fail to provide a public clone method. After
 discussion, TRC unanimously recommended that we should NOT modify the
 existing Cloneable interface, because of the compatibility impact.
 
 An alternative proposal was to add a new interface
 java.lang.PubliclyCloneable to reflect the original intended purpose
 of Cloneable. By a 5 to 2 majority, TRC recommended against this. 
 The main concern was that this would add yet more confusion (including
 spelling confusion!) to an already confused picture.
 
 TRC unanimously recommended that we should add additional
 documentation to the existing Cloneable interface to better describe
 how it is intended to be used and to describe "best practices" for
 implementors.
</blockquote>

So, although this is not directly about deprecated, the reason for not making Cloneable "deprecated" is that Technical Review Comitee decided that modifying existing documentation will be sufficient enough to make this interface useful. And so they did. Until Java 1.4, <code>Cloneable</code> was documented as follows:

<blockquote>
 A class implements the Cloneable interface to indicate to the
 Object.clone() method that it is legal for that method to make a
 field-for-field copy of instances of that class. 
 
 Attempts to clone instances that do not implement the Cloneable
 interface result in the exception CloneNotSupportedException being
 thrown. 
 
 The interface Cloneable declares no methods.
</blockquote>

Since Java 1.4 (which was released in February 2002) up to current edition (Java 8) it looks like this:

<blockquote>
 A class implements the Cloneable interface to indicate to the
 Object.clone() method that it is legal for that method to make a
 field-for-field copy of instances of that class. Invoking Object's
 clone method on an instance that does not implement the Cloneable
 interface results in the exception CloneNotSupportedException being
 thrown. 
 
 By convention, classes that implement this interface should override
 Object.clone (which is protected) with a public method. See
 Object.clone() for details on overriding this method. 
 
 Note that this interface does not contain the clone method. Therefore,
 it is not possible to clone an object merely by virtue of the fact
 that it implements this interface. Even if the clone method is invoked
 reflectively, there is no guarantee that it will succeed.
</blockquote>

blocks|key|2724737|text|简短的回答是“为什么Cloneable不被弃用？”(或者实际上，对于任何X，为什么X没有被弃用)是因为人们没有太多地关注对它们的弃用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2724738|大多数最近被弃用的东西都被弃用了，因为有一个具体的计划来删除它们。例如，LogManager的addPropertyChangeListener和removePropertyChangeListener方法是deprecated+in+Java+SE+8，目的是在JavaSE9中删除它们(原因是它们不必要地使模块相互依赖关系变得复杂)。实际上，这些API已经成为removed+from+early+JDK+9开发版本。(请注意，类似的属性更改侦听器调用也已从Pack200中删除；请参阅JDK-8029806。)|2724739|对于Cloneable和Object.clone()，没有类似的计划。|2724740|更长的答案将涉及讨论进一步的问题，例如，人们可能会期望这些API发生什么，如果它们被弃用，平台将产生什么成本或好处，以及当API被弃用时，将向开发人员传达什么。我在最近的JavaOne演讲Debt+and+Deprecation中探讨了这个话题。(可通过该链接查看幻灯片；video+here。)事实证明，JDK本身在使用弃用方面并不是非常一致。它已经被用来表示几种不同的东西，例如，|2724741|这很危险，您应该意识到使用它的风险(例如：Thread.stop()、Thread.resume()和|2724742|Thread.stop()|unordered-list-item|2724743|2724744|2724745|这将在未来版本的|2724746|中删除|2724747|这已经过时了，最好使用一些不同的方法(例如：java.util.Date)中的许多|2724748|2724749|2724750|所有这些都是不同的含义，并且它们的不同子集适用于不推荐使用的不同事物。它们中的一些子集适用于没有被弃用的东西(但可能应该被弃用)。|2724751|Cloneable和Object.clone()是“坏的”，因为它们有设计缺陷，很难正确使用。但是，clone()仍然是复制数组的最佳方法，并且克隆对于复制精心实现的类的实例的用处有限。移除克隆将是一种不兼容的改变，它会破坏很多东西。克隆操作可以用不同的方式重新实现，但它可能比Object.clone()慢。|2724752|然而，在大多数情况下，复制构造函数比克隆更可取。因此，也许将Cloneable标记为“过时的”或“被取代的”或类似的东西将是合适的。这会告诉开发人员，他们可能想要寻找其他地方，但这不会表明克隆机制可能会在未来的版本中删除。不幸的是，不存在这样的标记。|2724753|在目前的情况下，“弃用”似乎意味着最终的删除--尽管有一小部分被弃用的特性曾经被删除过--因此，对于克隆机制来说，弃用似乎是不必要的。也许在未来，可以应用另一种标记，指导开发人员使用替代机制。|2724754|更新|BOLD|2724755|我已经在bug+report中添加了一些额外的历史记录。Frank+Yellin是一位早期的JVM实现者，也是JVM规范的合著者，他对other+answer引用的TRC建议中的“迷失在时间的迷雾中”的评论做了一些评论。我在这里引用了相关部分；完整的消息在bug报告中。|2724756|2724757|+Cloneable没有方法的原因与Serializable没有相同的原因。Cloneable表示类的属性，而不是专门说明类支持的方法。|blockquote|2724758|2724759|在反射之前，我们需要一个本机方法来制作对象的浅层副本。因此，Object.clone()诞生了。很明显，许多类都想要覆盖这个方法，而且并不是每个类都想被克隆。因此Cloneable的诞生表明了程序员的意图。|2724760|所以，简而言之。Cloneable的目的并不是表明您有一个公共的clone()方法。它表明您愿意使用Object.clone()进行克隆，并且由实现决定是否将clone()设置为公共的。|2724761|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/8/docs/api/java/util/logging/LogManager.html|1|https://bugs.openjdk.java.net/browse/JDK-7192274|2|https://bugs.openjdk.java.net/browse/jdk-8029805|3|https://bugs.openjdk.java.net/browse/JDK-8029806|4|https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377|5|https://www.parleys.com/talk/debt-deprecation|6|https://bugs.openjdk.java.net/browse/JDK-4098033|7|https://stackoverflow.com/a/26403314/1441122^0|A|9|10|1|15|1|0|1B|P|21|S|6F|7|10|A|0|2W|N|1|52|O|2|6T|B|3|0|2|9|C|E|0|2M|K|4|3S|A|5|0|L|D|Z|F|0|0|D|0|0|0|0|0|M|E|0|0|0|0|0|9|A|E|1E|7|3V|E|0|U|9|0|0|0|2|0|4|A|6|1V|C|7|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|28|8|@$9|29|A|2A|B|C]|$9|2B|A|2C|B|C]|$9|2D|A|2E|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|2F|8|@$9|2G|A|2H|B|C]|$9|2I|A|2J|B|C]|$9|2K|A|2L|B|C]]|D|@$9|2M|A|2N|1|2O]|$9|2P|A|2Q|1|2R]|$9|2S|A|2T|1|2U]|$9|2V|A|2W|1|2X]]|E|$]]|$1|H|3|I|5|6|7|2Y|8|@$9|2Z|A|30|B|C]|$9|31|A|32|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|33|8|@]|D|@$9|34|A|35|1|36]|$9|37|A|38|1|39]]|E|$]]|$1|L|3|M|5|6|7|3A|8|@$9|3B|A|3C|B|C]|$9|3D|A|3E|B|C]]|D|@]|E|$]]|$1|N|3|O|5|P|7|3F|8|@$9|3G|A|3H|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|3I|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|3J|8|@]|D|@]|E|$]]|$1|S|3|T|5|P|7|3K|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|3L|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|3M|8|@$9|3N|A|3O|B|C]]|D|@]|E|$]]|$1|Y|3|-4|5|P|7|3P|8|@]|D|@]|E|$]]|$1|Z|3|-4|5|6|7|3Q|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|3R|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|3S|8|@$9|3T|A|3U|B|C]|$9|3V|A|3W|B|C]|$9|3X|A|3Y|B|C]|$9|3Z|A|40|B|C]]|D|@]|E|$]]|$1|14|3|15|5|6|7|41|8|@$9|42|A|43|B|C]]|D|@]|E|$]]|$1|16|3|17|5|6|7|44|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|45|8|@$9|46|A|47|B|1A]]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|48|8|@]|D|@$9|49|A|4A|1|4B]|$9|4C|A|4D|1|4E]]|E|$]]|$1|1D|3|-4|5|6|7|4F|8|@]|D|@]|E|$]]|$1|1E|3|1F|5|1G|7|4G|8|@]|D|@]|E|$]]|$1|1H|3|-4|5|6|7|4H|8|@]|D|@]|E|$]]|$1|1I|3|1J|5|6|7|4I|8|@]|D|@]|E|$]]|$1|1K|3|1L|5|6|7|4J|8|@]|D|@]|E|$]]|$1|1M|3|-4|5|6|7|4K|8|@]|D|@]|E|$]]]|1N|$1O|$5|1P|1Q|1R|E|$1S|1T]]|1U|$5|1P|1Q|1R|E|$1S|1V]]|1W|$5|1P|1Q|1R|E|$1S|1X]]|1Y|$5|1P|1Q|1R|E|$1S|1Z]]|20|$5|1P|1Q|1R|E|$1S|21]]|22|$5|1P|1Q|1R|E|$1S|23]]|24|$5|1P|1Q|1R|E|$1S|25]]|26|$5|1P|1Q|1R|E|$1S|27]]]]

The short answer to &quot;why isn't <code>Cloneable</code> deprecated?&quot; (or indeed, why isn't <code>X</code> deprecated, for any <code>X</code>) is that there hasn't been much attention paid to deprecating them.
Most things that have been deprecated recently were deprecated because there is a specific plan to remove them. For example, the <code>addPropertyChangeListener</code> and <code>removePropertyChangeListener</code> methods of <a href="http://docs.oracle.com/javase/8/docs/api/java/util/logging/LogManager.html" rel="noreferrer">LogManager</a> were <a href="https://bugs.openjdk.java.net/browse/JDK-7192274" rel="noreferrer">deprecated in Java SE 8</a> with the intention of removing them in Java SE 9. (The reason is that they unnecessarily complicated module interdependencies.) Indeed, these APIs have already been <a href="https://bugs.openjdk.java.net/browse/jdk-8029805" rel="noreferrer">removed from early JDK 9</a> development builds. (Note that similar property change listener calls were also removed from <code>Pack200</code>; see <a href="https://bugs.openjdk.java.net/browse/JDK-8029806" rel="noreferrer">JDK-8029806</a>.)
No such similar plan exists to for <code>Cloneable</code> and <code>Object.clone()</code>.
A longer answer would involve discussing further questions, such as what one might expect to happen to these APIs, what costs or benefits would accrue the platform if they were deprecated, and what is being communicated to developers when an API is deprecated. I explored this topic in my recent JavaOne talk, <a href="https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377" rel="noreferrer">Debt and Deprecation</a>. (Slides available at that link; <a href="https://www.parleys.com/talk/debt-deprecation" rel="noreferrer">video here</a>.) It turns out that the JDK itself hasn't been very consistent in its usage of deprecation. It's been used to mean several different things, including for example,
<ul>
<li>This is dangerous and you should be aware of the risks of using it (example:<code>Thread.stop()</code>, <code>Thread.resume()</code>, and <code>Thread.suspend()</code>).
</li>
<li>This is going to be removed in a future release
</li>
<li>This is obsolete and it's a good idea for you to use something different (example: many of the methods in <code>java.util.Date</code>)
</li>
</ul>
All of these are distinct meanings, and different subsets of them apply to different things that are deprecated. And some subset of them apply to things that aren't deprecated (but that maybe should be deprecated).
<code>Cloneable</code> and <code>Object.clone()</code> are &quot;broken&quot; in the sense that they have design flaws and are difficult to use correctly. However, <code>clone()</code> is still the best way to copy arrays, and cloning has some limited usefulness to make copies of instances of classes that are carefully implemented. Removing cloning would be an incompatible change that would break a lot of things. A cloning operation could be reimplemented a different way, but it would probably be slower than <code>Object.clone()</code>.
However, for most things a copy constructor is preferable to cloning. So perhaps marking <code>Cloneable</code> as &quot;obsolete&quot; or &quot;superseded&quot; or something similar would be appropriate. This would tell developers that they probably want to look elsewhere, but it would not signal that the cloning mechanism might be removed in a future release. Unfortunately, no such marker exists.
As things stand, &quot;deprecation&quot; seems to imply eventual removal -- despite the fact that a vanishingly small number of deprecated features have ever been removed -- and so deprecation doesn't seem warranted for the cloning mechanism. Perhaps in the future an alternative marking can be applied that directs developers to use alternative mechanisms instead.
UPDATE
I've added some additional history to the <a href="https://bugs.openjdk.java.net/browse/JDK-4098033" rel="noreferrer">bug report</a>. Frank Yellin, an early JVM implementor and co-author of the JVM specification, made some comments in response to the &quot;lost in the mists of time&quot; comment in the TRC recommendation quoted in the <a href="https://stackoverflow.com/a/26403314/1441122">other answer</a>. I've quoted the relevant portions here; the full message is in the bug report.
<blockquote>
Cloneable has no methods for the same reason that Serializable doesn't. Cloneable indicates a property of the class, rather than specifically saying anything about the methods that the class supported.
Prior to reflection, we needed a native method to make a shallow copy of an Object. Hence Object.clone() was born. It was also clear that many classes would want to override this method, and that not every class would want to be cloned. Hence Cloneable was born to indicate the programmer's intention.
So, in short. The purpose of Cloneable was not to indicate that you had a public clone() method. It was to indicate that you were willing to be cloned using Object.clone(), and it was up to the implementation to decide whether or not to make clone() public.
</blockquote>

It is commonly understood that <code>Cloneable</code> interface in Java is broken. There are many reasons for this, which I will not mention; <a href="http://howtodoinjava.com/2012/11/10/cloneable-interface-is-broken-in-java/">others</a> already did it. It is also the position of <a href="http://www.artima.com/intv/bloch13.html">Java architects</a> themselves.

My question is therefore: why has is not been deprecated yet? If the core Java team have decided that it is broken, then they must also have considered deprecation. What are their reasons against doing so (in Java 8 it is <a href="http://docs.oracle.com/javase/8/docs/api/java/lang/Cloneable.html">still not deprecated</a>)?

Why is Cloneable not deprecated?

Java

人们通常认为Java中的Cloneable接口是坏的。这样做的原因有很多，我不会提及；已经做到了。这也是本身的立场。因此，我的问题是:为什么还没有被弃用？如果核心Java团队认为它已经坏了，那么他们一定也考虑过弃用。他们反对这样做的理由是什么(在Java8中是)？

问为什么Cloneable没有被弃用？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Cloneable没有被弃用？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Cloneable没有被弃用？
EN