| Class and Description |
|---|
| de.toem.impulse.javadoc.Doclet |
| java.io.LineNumberInputStream
This class incorrectly assumes that bytes adequately represent
characters. As of JDK 1.1, the preferred way to operate on
character streams is via the new character-stream classes, which
include a class for counting line numbers.
|
| de.toem.impulse.cells.view.PlotReference |
| de.toem.impulse.cells.view.SignalReference |
| java.io.StringBufferInputStream
This class does not properly convert characters into bytes. As
of JDK 1.1, the preferred way to create a stream from a
string is via the
StringReader class. |
| Method and Description |
|---|
| de.toem.impulse.samples.ISamplesWriter.addMember(String, String, int) |
| 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. |
| de.toem.impulse.samples.ISamplesWriter.attachLabel(int, int, int) |
| de.toem.impulse.samples.ISamplesWriter.attachLabel(String, int, int) |
| java.lang.SecurityManager.checkMulticast(InetAddress, byte)
Use #checkPermission(java.security.Permission) instead
|
| 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.Thread.destroy()
This method was originally designed to destroy this
thread without any cleanup. Any monitors it held would have
remained locked. However, the method was never implemented.
If if were to be implemented, it would be deadlock-prone in
much the manner of
Thread.suspend(). If the target thread held
a lock protecting a critical system resource when it was
destroyed, no thread could ever access this resource again.
If another thread ever attempted to lock this resource, deadlock
would result. Such deadlocks typically manifest themselves as
"frozen" processes. For more information, see
Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?. |
| de.toem.impulse.values.GroupedValue.get(int) |
| java.lang.String.getBytes(int, int, byte[], int)
This method does not properly convert characters into
bytes. As of JDK 1.1, the preferred way to do this is via the
String.getBytes() method, which uses the platform's default charset. |
| de.toem.impulse.values.GroupedValue.getEvents() |
| java.lang.SecurityManager.getInCheck()
This type of security checking is not recommended.
It is recommended that the
checkPermission
call be used instead. |
| java.lang.Runtime.getLocalizedInputStream(InputStream)
As of JDK 1.1, the preferred way to translate a byte
stream in the local encoding into a character stream in Unicode is via
the
InputStreamReader and BufferedReader
classes. |
| java.lang.Runtime.getLocalizedOutputStream(OutputStream)
As of JDK 1.1, the preferred way to translate a
Unicode character stream into a byte stream in the local encoding is via
the
OutputStreamWriter, BufferedWriter, and
PrintWriter classes. |
| de.toem.impulse.samples.IPackedSamples.getMessage() |
| de.toem.impulse.values.GroupedValue.hasConflict() |
| de.toem.impulse.samples.ISamples.hasConflict() |
| de.toem.impulse.values.CompoundValue.isConflict() |
| de.toem.impulse.samples.IReadableSample.isConflict() |
| java.lang.Character.isJavaLetter(char)
Replaced by isJavaIdentifierStart(char).
|
| java.lang.Character.isJavaLetterOrDigit(char)
Replaced by isJavaIdentifierPart(char).
|
| java.lang.Character.isSpace(char)
Replaced by isWhitespace(char).
|
| java.io.ObjectInputStream.readLine()
This method does not properly convert bytes to characters.
see DataInputStream for the details and alternatives.
|
| java.io.DataInputStream.readLine()
This method does not properly convert bytes to characters.
As of JDK 1.1, the preferred way to read lines of text is via the
BufferedReader.readLine() method. Programs that use the
DataInputStream class to read lines can be converted to use
the BufferedReader class by replacing code of the form:
|
| 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.Runtime.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()
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?. |
| java.io.ByteArrayOutputStream.toString(int)
This method does not properly convert bytes into characters.
As of JDK 1.1, the preferred way to do this is via the
toString(String enc) method, which takes an encoding-name
argument, or the toString() method, which uses the
platform's default character encoding. |
| java.io.File.toURL()
This method does not automatically escape characters that
are illegal in URLs. It is recommended that new code convert an
abstract pathname into a URL by first converting it into a URI, via the
toURI method, and then converting the URI into a URL
via the URI.toURL method. |
| de.toem.impulse.samples.ILogicSamplesWriter.write(long, Logic) |
| java.io.ObjectOutputStream.PutField.write(ObjectOutput)
This method does not write the values contained by this
PutField object in a proper format, and may
result in corruption of the serialization stream. The
correct way to write PutField data is by
calling the ObjectOutputStream.writeFields()
method. |
| de.toem.impulse.samples.ILogicSamplesWriter.writeLogic(long, Logic) |
| Constructor and Description |
|---|
| java.io.StreamTokenizer(InputStream)
As of JDK version 1.1, the preferred way to tokenize an
input stream is to convert it into a character stream, for example:
Reader r = new BufferedReader(new InputStreamReader(is)); StreamTokenizer st = new StreamTokenizer(r); |
| java.lang.String(byte[], int)
This method does not properly convert bytes into
characters. As of JDK 1.1, the preferred way to do this is via the
String constructors that take a Charset, charset name, or that use the platform's
default charset. |
| java.lang.String(byte[], int, int, int)
This method does not properly convert bytes into characters.
As of JDK 1.1, the preferred way to do this is via the
String constructors that take a Charset, charset name, or that use the platform's
default charset. |