archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-08-27 14:54:52 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

8220249: fix headings in java.compiler

Browse source 
Reviewed-by: erikj, darcy
This commit is contained in:
Jonathan Gibbons 2019-03-20 15:35:26 -07:00
parent 7bb74f80da
commit 2df0f4b4dd
52 changed files with 250 additions and 250 deletions
Download patch file Download diff file Expand all files Collapse all files

2
src/java.base/share/classes/java/lang/doc-files/ValueBased.html
View file

@ -5,7 +5,7 @@
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
<h2 id="ValueBased">Value-based Classes</h2>
<h1 id="ValueBased">Value-based Classes</h1>
Some classes, such as <code>java.util.Optional</code> and
<code>java.time.LocalDateTime</code>, are <em>value-based</em>. Instances of a

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

@ -1,6 +1,6 @@
<!doctype html>
<!--
Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved.
Copyright (c) 2005, 2019, 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
@ -29,9 +29,9 @@
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
<h2>Java Thread Primitive Deprecation</h2>
<h1>Java Thread Primitive Deprecation</h1>
<hr>
<h3>Why is <code>Thread.stop</code> deprecated?</h3>
<h2>Why is <code>Thread.stop</code> deprecated?</h2>
<p>Because it is inherently unsafe. Stopping a thread causes it to
unlock all the monitors that it has locked. (The monitors are
unlocked as the <code>ThreadDeath</code> exception propagates up
@ -46,8 +46,8 @@ no warning that his program may be corrupted. The corruption can
manifest itself at any time after the actual damage occurs, even
hours or days in the future.</p>
<hr>
<h3>Couldn't I just catch the <code>ThreadDeath</code> exception
and fix the damaged object?</h3>
<h2>Couldn't I just catch the <code>ThreadDeath</code> exception
and fix the damaged object?</h2>
<p>In theory, perhaps, but it would <em>vastly</em> complicate the
task of writing correct multithreaded code. The task would be
nearly insurmountable for two reasons:</p>
@ -62,7 +62,7 @@ it succeeded. The code to ensure this would be quite complex.</li>
</ol>
In sum, it just isn't practical.
<hr>
<h3>What should I use instead of <code>Thread.stop</code>?</h3>
<h2>What should I use instead of <code>Thread.stop</code>?</h2>
<p>Most uses of <code>stop</code> 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
@ -117,8 +117,8 @@ applet's <code>stop</code> and <code>run</code> methods with:
}
</pre>
<hr>
<h3>How do I stop a thread that waits for long periods (e.g., for
input)?</h3>
<h2>How do I stop a thread that waits for long periods (e.g., for
input)?</h2>
<p>That's what the <code>Thread.interrupt</code> method is for. The
same "state based" signaling mechanism shown above can be used, but
the state change (<code>blinker = null</code>, in the previous
@ -145,8 +145,8 @@ following incantation:
This ensures that the Thread will reraise the
<code>InterruptedException</code> as soon as it is able.
<hr>
<h3>What if a thread doesn't respond to
<code>Thread.interrupt</code>?</h3>
<h2>What if a thread doesn't respond to
<code>Thread.interrupt</code>?</h2>
<p>In some cases, you can use application specific tricks. For
example, if a thread is waiting on a known socket, you can close
the socket to cause the thread to return immediately.
@ -158,8 +158,8 @@ cases include deliberate denial-of-service attacks, and I/O
operations for which thread.stop and thread.interrupt do not work
properly.</p>
<hr>
<h3>Why are <code>Thread.suspend</code> and
<code>Thread.resume</code> deprecated?</h3>
<h2>Why are <code>Thread.suspend</code> and
<code>Thread.resume</code> deprecated?</h2>
<p><code>Thread.suspend</code> 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
@ -168,8 +168,8 @@ would resume the target thread attempts to lock this monitor prior
to calling <code>resume</code>, deadlock results. Such deadlocks
typically manifest themselves as "frozen" processes.</p>
<hr>
<h3>What should I use instead of <code>Thread.suspend</code> and
<code>Thread.resume</code>?</h3>
<h2>What should I use instead of <code>Thread.suspend</code> and
<code>Thread.resume</code>?</h2>
<p>As with <code>Thread.stop</code>, the prudent approach is to
have the "target thread" poll a variable indicating the desired
state of the thread (active or suspended). When the desired state
@ -283,8 +283,8 @@ The resulting <code>run</code> method is:
}
</pre>
<hr size="3" noshade="noshade" />
<h3>Can I combine the two techniques to produce a thread that may
be safely "stopped" or "suspended"?</h3>
<h2>Can I combine the two techniques to produce a thread that may
be safely "stopped" or "suspended"?</h2>
Yes, it's reasonably straightforward. The one subtlety is that the
target thread may already be suspended at the time that another
thread tries to stop it. If the <code>stop</code> method merely sets