Deprecated API

Deprecated Methods

java.lang.ThreadGroup.allowThreadSuspension(boolean)
The definition of this call depends on ThreadGroup.suspend(), which is deprecated. Further, the behavior of this call was never specified.

java.lang.Thread.countStackFrames()
The definition of this call depends on Thread.suspend(), which is deprecated. Further, the results of this call were never well-defined.

java.lang.System.getenv(String)
The preferred way to extract system-dependent information is the system properties of the java.lang.System.getProperty methods and the corresponding getTypeName methods of the Boolean, Integer, and Long primitive types. For example:

     String classPath = System.getProperty("java.class.path",".");
 

     if (Boolean.getBoolean("myapp.exper.mode"))
         enableExpertCommands();
 

java.lang.ThreadGroup.resume()
This method is used solely in conjunction with Thread.suspend and ThreadGroup.suspend, both of which have been deprecated, as they are inherently deadlock-prone. See Thread.suspend() for details.

java.lang.Thread.resume()
This method exists solely for use with Thread.suspend(), which has been deprecated because it is deadlock-prone. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.

java.lang.System.runFinalizersOnExit(boolean)
This method 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.

java.lang.ThreadGroup.stop()
This method is inherently unsafe. See Thread.stop() for details.

java.lang.Thread.stop()
This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.

java.lang.Thread.stop(Throwable)
This method is inherently unsafe. See Thread.stop() (with no arguments) for details. An additional danger of this method is that it may be used to generate exceptions that the target thread is unprepared to handle (including checked exceptions that the thread could not possibly throw, were it not for this method). For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.

java.lang.ThreadGroup.suspend()
This method is inherently deadlock-prone. See Thread.suspend() for details.

java.lang.Thread.suspend()
This method has been deprecated, as it is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.