< prev index next >

src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html

Print this page

        

*** 1,8 **** <!doctype html> <!-- ! Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. This code is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 only, as published by the Free Software Foundation. Oracle designates this --- 1,8 ---- <!doctype html> <!-- ! Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved. DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. This code is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 only, as published by the Free Software Foundation. Oracle designates this
*** 344,364 **** <code>Thread.destroy</code> was never implemented and has been deprecated. If it were implemented, it would be deadlock-prone in the manner of <code>Thread.suspend</code>. (In fact, it is roughly equivalent to <code>Thread.suspend</code> without the possibility of a subsequent <code>Thread.resume</code>.) - <hr> - <h3>Why is <code>Runtime.runFinalizersOnExit</code> - deprecated?</h3> - Because it is inherently unsafe. It may result in finalizers being - called on live objects while other threads are concurrently - manipulating those objects, resulting in erratic behavior or - deadlock. While this problem could be prevented if the class whose - objects are being finalized were coded to "defend against" this - call, most programmers do <i>not</i> defend against it. They assume - that an object is dead at the time that its finalizer is called. - <p>Further, the call is not "thread-safe" in the sense that it sets - a VM-global flag. This forces <i>every</i> class with a finalizer - to defend against the finalization of live objects!</p> <p><!-- Body text ends here --></p> </body> </html> --- 344,351 ----
< prev index next >