libjava/classpath/ChangeLog.gcj:

2007-05-31  Matthias Klose  <doko@ubuntu.com>

        * javax/management/NotificationBroadcasterSupport.java
        (getNotificationInfo): Add cast.
        * native/jni/qt-peer/Makefile.am (AM_CXXFLAGS): Add libstdc++ include
        directories.
        * native/jni/qt-peer/Makefile.in: Regenerate.

libjava/ChangeLog:

2007-06-03  Matthias Klose  <doko@ubuntu.com>

        * java/io/natFileWin32.cc (setFilePermissions): New (stub only).
        _access: Handle EXEC query, stub only.

2007-06-03  Matthias Klose  <doko@ubuntu.com>

        Merged from classpath:
        * gnu/java/nio/SelectorProviderImpl.java: Whitespace merge.
        * java/lang/System.java(inheritedChannel): New.
        * java/lang/Character.java: Remove stray`;'.
        * java/net/MulticastSocket.java: Merged.
        * java/text/DateFormatSymbols.java(getInstance): New, comment updates.
        * java/text/Collator.java(getInstance): Merged.
        * java/util/Calendar.java: New attributes ALL_STYLES, SHORT, LONG.
        getDisplayName, getDisplayNames: New.
        * java/util/logging/Logger.java: Merged.
        * Regenerate .class and .h files.

2007-06-03  Matthias Klose  <doko@ubuntu.com>

        * java/io/File.java: Merge with classpath-0.95, new method
        setFilePermissions, new attribute EXEC.
        * java/io/natFilePosix.cc (setFilePermissions): New.
        _access: Handle EXEC query.
        * classpath/lib/java/io/File.class, java/io/File.h: Regenerate.

2007-06-03  Matthias Klose  <doko@ubuntu.com>

        Imported GNU Classpath 0.95.

        * classpath/Makefile.in,
        classpath/native/jni/midi-dssi/Makefile.in,
        classpath/native/jni/classpath/Makefile.in,
        classpath/native/jni/Makefile.in,
        classpath/native/jni/gconf-peer/Makefile.in,
        classpath/native/jni/java-io/Makefile.in,
        classpath/native/jni/native-lib/Makefile.in,
        classpath/native/jni/java-util/Makefile.in,
        classpath/native/jni/midi-alsa/Makefile.in,
        classpath/native/jni/java-lang/Makefile.in,
        classpath/native/jni/java-nio/Makefile.in,
        classpath/native/jni/java-net/Makefile.in,
        classpath/native/jni/xmlj/Makefile.in,
        classpath/native/jni/qt-peer/Makefile.in,
        classpath/native/jni/gtk-peer/Makefile.in,
        classpath/native/Makefile.in, classpath/native/jawt/Makefile.in,
        classpath/native/fdlibm/Makefile.in,
        classpath/native/plugin/Makefile.in,
        classpath/resource/Makefile.in, classpath/scripts/Makefile.in,
        classpath/tools/Makefile.in, classpath/doc/Makefile.in,
        classpath/doc/api/Makefile.in, classpath/lib/Makefile.in,
        classpath/external/Makefile.in, classpath/external/jsr166/Makefile.in,
        classpath/external/sax/Makefile.in,
        classpath/external/w3c_dom/Makefile.in,
        classpath/external/relaxngDatatype/Makefile.in,
        classpath/include/Makefile.in,
        classpath/examples/Makefile.in: Regenerate.
        * classpath/config.guess, classpath/config.sub,
        classpath/ltmain.sh : Update.
        * classpath/configure, classpath/depcomp, classpath/missing,
        classpath/aclocal.m4, classpath/install-sh: Regenerate.

        * gnu/classpath/Configuration.java (CLASSPATH_VERSION): Now 0.95.
        * sources.am: Regenerate.
        * Makefile.in: Regenerate.

        * Update the .class files and generated CNI header files, add new
        .class and generated CNI header files.
        * Remove generated files for removed java source files:
        classpath/gnu/java/net/BASE64.java,
        classpath/gnu/java/security/util/Base64.java,
        classpath/gnu/java/awt/peer/gtk/GThreadMutex.java,
        classpath/gnu/java/awt/peer/gtk/GThreadNativeMethodRunner.java,
        classpath/gnu/java/awt/font/autofit/Scaler.java,
        classpath/gnu/classpath/jdwp/util/Value.java,
        classpath/gnu/javax/net/ssl/Base64.java.
        * Remove empty directories.

        * Makefile.am(nat_source_files): Add natVMOperatingSystemMXBeanImpl.cc.
        * java/lang/Class.java(setAccessible): Merge from classpath.
        * java/util/Locale.java: Remove.
        * gnu/java/lang/management/VMOperatingSystemMXBeanImpl.java,
        gnu/java/lang/management/natVMOperatingSystemMXBeanImpl.cc: New.
        * gcj/javaprims.h: Update class declarations.
        * scripts/classes.pl: Update usage.
        * HACKING: Mention to build all peers.

From-SVN: r125302

4 files changed, 1 insertions, 431 deletions

diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java b/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java
index 52cd17a..bbb00a0 100644
--- a/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java
+++ b/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java
@@ -866,7 +866,7 @@ public class ConcurrentSkipListMap<K,V> extends AbstractMap<K,V>
                 if (n != null) {
                     Node<K,V> f = n.next;
                     if (n != b.next)               // inconsistent read
-                        break;;
+                        break;
                     Object v = n.value;
                     if (v == null) {               // n is deleted
                         n.helpDelete(b, f);
diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html b/libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html
deleted file mode 100644
index 6bc191d..0000000
--- a/libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html
+++ /dev/null
@@ -1,158 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
-<html> <head>
-<title>Atomics</title>
-</head>
-
-<body>
-
-A small toolkit of classes that support lock-free thread-safe
-programming on single variables. In essence, the classes in this
-package extend the notion of <tt>volatile</tt> values, fields, and
-array elements to those that also provide an atomic conditional update
-operation of the form:
-
-<pre>
-  boolean compareAndSet(expectedValue, updateValue);
-</pre>
-
-<p> This method (which varies in argument types across different
-classes) atomically sets a variable to the <tt>updateValue</tt> if it
-currently holds the <tt>expectedValue</tt>, reporting <tt>true</tt> on
-success.  The classes in this package also contain methods to get and
-unconditionally set values, as well as a weaker conditional atomic
-update operation <tt>weakCompareAndSet</tt> desribed below.
-
-<p> The specifications of these methods enable implementations to
-employ efficient machine-level atomic instructions that are available
-on contemporary processors. However on some platforms, support may
-entail some form of internal locking. Thus the methods are not
-strictly guaranteed to be non-blocking --
-a thread may block transiently before performing the operation.
-
-<p> Instances of classes {@link
-java.util.concurrent.atomic.AtomicBoolean}, {@link
-java.util.concurrent.atomic.AtomicInteger}, {@link
-java.util.concurrent.atomic.AtomicLong}, and {@link
-java.util.concurrent.atomic.AtomicReference} each provide access and
-updates to a single variable of the corresponding type.  Each class
-also provides appropriate utility methods for that type.  For example,
-classes <tt>AtomicLong</tt> and <tt>AtomicInteger</tt> provide atomic
-increment methods.  One application is to generate sequence numbers,
-as in:
-
-<pre>
-class Sequencer {
-  private AtomicLong sequenceNumber = new AtomicLong(0);
-  public long next() { return sequenceNumber.getAndIncrement(); }
-}
-</pre>
-
-<p>The memory effects for accesses and updates of atomics generally
-follow the rules for volatiles, as stated in <a
-href="http://java.sun.com/docs/books/jls/"> The Java Language
-Specification, Third Edition (17.4 Memory Model)</a>:
-
-<ul>
-
-  <li> <tt>get</tt> has the memory effects of reading a
-<tt>volatile</tt> variable.
-
-  <li> <tt>set</tt> has the memory effects of writing (assigning) a
-<tt>volatile</tt> variable.
-
-  <li> <tt>lazySet</tt> has the memory effects of writing (assigning)
-  a <tt>volatile</tt> variable except that it permits reorderings with
-  subsequent (but not previous) memory actions that do not themselves
-  impose reordering constraints with ordinary non-<tt>volatile</tt>
-  writes.  Among other usage contexts, <tt>lazySet</tt> may apply when
-  nulling out, for the sake of garbage collection, a reference that is
-  never accessed again.
-
-  <li><tt>weakCompareAndSet</tt> atomically reads and conditionally
-  writes a variable but does <em>not</em>
-  create any happens-before orderings, so provides no guarantees
-  with respect to previous or subsequent reads and writes of any
-  variables other than the target of the <tt>weakCompareAndSet</tt>.
-
-  <li> <tt>compareAndSet</tt>
-  and all other read-and-update operations such as <tt>getAndIncrement</tt>
-  have the memory effects of both reading and
-  writing <tt>volatile</tt> variables.
-</ul>
-
-<p>In addition to classes representing single values, this package
-contains <em>Updater</em> classes that can be used to obtain
-<tt>compareAndSet</tt> operations on any selected <tt>volatile</tt>
-field of any selected class.  {@link
-java.util.concurrent.atomic.AtomicReferenceFieldUpdater}, {@link
-java.util.concurrent.atomic.AtomicIntegerFieldUpdater}, and {@link
-java.util.concurrent.atomic.AtomicLongFieldUpdater} are
-reflection-based utilities that provide access to the associated field
-types. These are mainly of use in atomic data structures in which
-several <tt>volatile</tt> fields of the same node (for example, the
-links of a tree node) are independently subject to atomic
-updates. These classes enable greater flexibility in how and when to
-use atomic updates, at the expense of more awkward reflection-based
-setup, less convenient usage, and weaker guarantees.
-
-<p>The {@link java.util.concurrent.atomic.AtomicIntegerArray}, {@link
-java.util.concurrent.atomic.AtomicLongArray}, and {@link
-java.util.concurrent.atomic.AtomicReferenceArray} classes further
-extend atomic operation support to arrays of these types. These
-classes are also notable in providing <tt>volatile</tt> access
-semantics for their array elements, which is not supported for
-ordinary arrays.
-
-<p>The atomic classes also support method <tt>weakCompareAndSet</tt>,
-which has limited applicability. On some platforms, the weak version
-may be more efficient than <tt>compareAndSet</tt> in the normal case,
-but differs in that any given invocation of <tt>weakCompareAndSet</tt>
-method may return <tt>false</tt> spuriously (that is, for no apparent
-reason). A <tt>false</tt> return means only that the operation may be
-retried if desired, relying on the guarantee that repeated invocation
-when the variable holds <tt>expectedValue</tt> and no other thread is
-also attempting to set the variable will eventually succeed.  (Such
-spurious failures may for example be due to memory contention effects
-that are unrelated to whether the expected and current values are
-equal.)  Additionally <tt>weakCompareAndSet</tt> does not provide
-ordering guarantees that are usually needed for synchronization
-control.  However, the method may be useful for updating counters and
-statistics when such updates are unrelated to the other happens-before
-orderings of a program. When a thread sees an update to an atomic
-variable caused by a <tt>weakCompareAndSet</tt>, it does not
-necessarily see updates to any <em>other</em> variables that occurred
-before the <tt>weakCompareAndSet</tt>.  This may be acceptable when
-for example updating performance statistics, but rarely otherwise.
-
-<p> The {@link java.util.concurrent.atomic.AtomicMarkableReference}
-class associates a single boolean with a reference. For example, this
-bit might be used inside a data structure to mean that the object
-being referenced has logically been deleted. The {@link
-java.util.concurrent.atomic.AtomicStampedReference} class associates
-an integer value with a reference. This may be used for example, to
-represent version numbers corresponding to series of updates.
-
-<p> Atomic classes are designed primarily as building blocks for
-implementing non-blocking data structures and related infrastructure
-classes.  The <tt>compareAndSet</tt> method is not a general
-replacement for locking. It applies only when critical updates for an
-object are confined to a <em>single</em> variable.
-
-<p> Atomic classes are not general purpose replacements for
-<tt>java.lang.Integer</tt> and related classes. They do <em>not</em>
-define methods such as <tt>hashCode</tt> and
-<tt>compareTo</tt>. (Because atomic variables are expected to be
-mutated, they are poor choices for hash table keys.)  Additionally,
-classes are provided only for those types that are commonly useful in
-intended applications. For example, there is no atomic class for
-representing <tt>byte</tt>. In those infrequent cases where you would
-like to do so, you can use an <tt>AtomicInteger</tt> to hold
-<tt>byte</tt> values, and cast appropriately. You can also hold floats
-using <tt>Float.floatToIntBits</tt> and <tt>Float.intBitstoFloat</tt>
-conversions, and doubles using <tt>Double.doubleToLongBits</tt> and
-<tt>Double.longBitsToDouble</tt> conversions.
-
-
-@since 1.5
-
-</body> </html>
diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html b/libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html
deleted file mode 100644
index 4b94525..0000000
--- a/libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html
+++ /dev/null
@@ -1,50 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
-<html> <head>
-<title>Locks</title>
-</head>
-
-<body>
-
-Interfaces and classes providing a framework for locking and waiting
-for conditions that is distinct from built-in synchronization and
-monitors. The framework permits much greater flexibility in the use of
-locks and conditions, at the expense of more awkward syntax.
-
-<p> The {@link java.util.concurrent.locks.Lock} interface supports
-locking disciplines that differ in semantics (reentrant, fair, etc),
-and that can be used in non-block-structured contexts including
-hand-over-hand and lock reordering algorithms. The main implementation
-is {@link java.util.concurrent.locks.ReentrantLock}.
-
-<p> The {@link java.util.concurrent.locks.ReadWriteLock} interface
-similarly defines locks that may be shared among readers but are
-exclusive to writers.  Only a single implementation, {@link
-java.util.concurrent.locks.ReentrantReadWriteLock}, is provided, since
-it covers most standard usage contexts. But programmers may create
-their own implementations to cover nonstandard requirements.
-
-<p> The {@link java.util.concurrent.locks.Condition} interface
-describes condition variables that may be associated with Locks.
-These are similar in usage to the implicit monitors accessed using
-<tt>Object.wait</tt>, but offer extended capabilities.  In particular,
-multiple <tt>Condition</tt> objects may be associated with a single
-<tt>Lock</tt>.  To avoid compatibility issues, the names of
-<tt>Condition</tt> methods are different than the corresponding
-<tt>Object</tt> versions.
-
-<p> The {@link java.util.concurrent.locks.AbstractQueuedSynchronizer}
-class serves as a useful superclass for defining locks and other
-synchronizers that rely on queuing blocked threads.  The {@link
-java.util.concurrent.locks.AbstractQueuedLongSynchronizer} class
-provides the same functionality but extends support to 64 bits of
-synchronization state. Both extend class {@link
-java.util.concurrent.locks.AbstractOwnableSynchronizer}, a simple
-class that helps record the thread currently holding exclusive
-synchronization.  The {@link java.util.concurrent.locks.LockSupport}
-class provides lower-level blocking and unblocking support that is
-useful for those developers implementing their own customized lock
-classes.
-
-@since 1.5
-
-</body> </html>
diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/package.html b/libjava/classpath/external/jsr166/java/util/concurrent/package.html
deleted file mode 100644
index 20227e1f..0000000
--- a/libjava/classpath/external/jsr166/java/util/concurrent/package.html
+++ /dev/null
@@ -1,222 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
-<html> <head>
-<title>Concurrency Utilities</title>
-</head>
-
-<body>
-
-<p> Utility classes commonly useful in concurrent programming.  This
-package includes a few small standardized extensible frameworks, as
-well as some classes that provide useful functionality and are
-otherwise tedious or difficult to implement.  Here are brief
-descriptions of the main components. See also the <tt>locks</tt> and
-<tt>atomic</tt> packages.
-
-<h2>Executors</h2>
-
-<b>Interfaces.</b> {@link java.util.concurrent.Executor} is a simple
-standardized interface for defining custom thread-like subsystems,
-including thread pools, asynchronous IO, and lightweight task
-frameworks.  Depending on which concrete Executor class is being used,
-tasks may execute in a newly created thread, an existing
-task-execution thread, or the thread calling <tt>execute()</tt>, and
-may execute sequentially or concurrently.  {@link
-java.util.concurrent.ExecutorService} provides a more complete
-asynchronous task execution framework.  An ExecutorService manages
-queuing and scheduling of tasks, and allows controlled shutdown.  The
-{@link java.util.concurrent.ScheduledExecutorService} subinterface
-and associated interfaces add support for delayed and periodic task execution.
-ExecutorServices provide methods arranging asynchronous execution of
-any function expressed as {@link java.util.concurrent.Callable}, the
-result-bearing analog of {@link java.lang.Runnable}.  A {@link
-java.util.concurrent.Future} returns the results of a function, allows
-determination of whether execution has completed, and provides a means to
-cancel execution.  A {@link java.util.concurrent.RunnableFuture} is
-a Future that possesses a <tt>run</tt> method that upon execution,
-sets its results.
-
-<p>
-
-<b>Implementations.</b> Classes {@link
-java.util.concurrent.ThreadPoolExecutor} and {@link
-java.util.concurrent.ScheduledThreadPoolExecutor} provide tunable,
-flexible thread pools. The {@link java.util.concurrent.Executors}
-class provides factory methods for the most common kinds and
-configurations of Executors, as well as a few utility methods for
-using them. Other utilities based on Executors include the concrete
-class {@link java.util.concurrent.FutureTask} providing a common
-extensible implementation of Futures, and {@link
-java.util.concurrent.ExecutorCompletionService}, that assists in
-coordinating the processing of groups of asynchronous tasks.
-
-<h2>Queues</h2>
-
-The java.util.concurrent {@link
-java.util.concurrent.ConcurrentLinkedQueue} class supplies an
-efficient scalable thread-safe non-blocking FIFO queue.  Five
-implementations in java.util.concurrent support the extended {@link
-java.util.concurrent.BlockingQueue} interface, that defines blocking
-versions of put and take: {@link
-java.util.concurrent.LinkedBlockingQueue}, {@link
-java.util.concurrent.ArrayBlockingQueue}, {@link
-java.util.concurrent.SynchronousQueue}, {@link
-java.util.concurrent.PriorityBlockingQueue}, and {@link
-java.util.concurrent.DelayQueue}. The different classes cover the most
-common usage contexts for producer-consumer, messaging, parallel
-tasking, and related concurrent designs. The {@link
-java.util.concurrent.BlockingDeque} interface extends
-<tt>BlockingQueue</tt> to support both FIFO and LIFO (stack-based)
-operations. Class {@link java.util.concurrent.LinkedBlockingDeque}
-provides an implementation.
-
-
-<h2>Timing</h2>
-
-The {@link java.util.concurrent.TimeUnit} class provides multiple
-granularities (including nanoseconds) for specifying and controlling
-time-out based operations.  Most classes in the package contain
-operations based on time-outs in addition to indefinite waits.  In all
-cases that time-outs are used, the time-out specifies the minimum time
-that the method should wait before indicating that it
-timed-out.  Implementations make a &quot;best effort&quot; to detect
-time-outs as soon as possible after they occur.  However, an indefinite
-amount of time may elapse between a time-out being detected and a
-thread actually executing again after that time-out.  All methods
-that accept timeout parameters treat values less than or equal to
-zero to mean not to wait at all.  To wait "forever", you can use
-a value of <tt>Long.MAX_VALUE</tt>.
-
-<h2>Synchronizers</h2>
-
-Four classes aid common special-purpose synchronization idioms.
-{@link java.util.concurrent.Semaphore} is a classic concurrency tool.
-{@link java.util.concurrent.CountDownLatch} is a very simple yet very
-common utility for blocking until a given number of signals, events,
-or conditions hold.  A {@link java.util.concurrent.CyclicBarrier} is a
-resettable multiway synchronization point useful in some styles of
-parallel programming. An {@link java.util.concurrent.Exchanger} allows
-two threads to exchange objects at a rendezvous point, and is useful
-in several pipeline designs.
-
-<h2>Concurrent Collections</h2>
-
-Besides Queues, this package supplies Collection implementations
-designed for use in multithreaded contexts:
-{@link java.util.concurrent.ConcurrentHashMap},
-{@link java.util.concurrent.ConcurrentSkipListMap},
-{@link java.util.concurrent.ConcurrentSkipListSet},
-{@link java.util.concurrent.CopyOnWriteArrayList}, and
-{@link java.util.concurrent.CopyOnWriteArraySet}.
-When many threads are expected to access a given collection,
-a <tt>ConcurrentHashMap</tt> is normally preferable to
-a synchronized <tt>HashMap</tt>, and a
-<tt>ConcurrentSkipListMap</tt> is normally preferable
-to a synchronized <tt>TreeMap</tt>. A
-<tt>CopyOnWriteArrayList</tt> is preferable to
-a synchronized <tt>ArrayList</tt> when the expected number of reads
-and traversals greatly outnumber the number of updates to a list.
-
-<p>The "Concurrent" prefix used with some classes in this package is a
-shorthand indicating several differences from similar "synchronized"
-classes. For example <tt>java.util.Hashtable</tt> and
-<tt>Collections.synchronizedMap(new HashMap())</tt> are
-synchronized. But {@link java.util.concurrent.ConcurrentHashMap} is
-"concurrent".  A concurrent collection is thread-safe, but not
-governed by a single exclusion lock. In the particular case of
-ConcurrentHashMap, it safely permits any number of concurrent reads as
-well as a tunable number of concurrent writes.  "Synchronized" classes
-can be useful when you need to prevent all access to a collection via
-a single lock, at the expense of poorer scalability. In other cases in
-which multiple threads are expected to access a common collection,
-"concurrent" versions are normally preferable. And unsynchronized
-collections are preferable when either collections are unshared, or
-are accessible only when holding other locks.
-
-<p> Most concurrent Collection implementations (including most Queues)
-also differ from the usual java.util conventions in that their Iterators
-provide <em>weakly consistent</em> rather than fast-fail traversal. A
-weakly consistent iterator is thread-safe, but does not necessarily
-freeze the collection while iterating, so it may (or may not) reflect
-any updates since the iterator was created.
-
-<a name="MemoryVisibility">
-<h2> Memory Consistency Properties </h2>
-
-<a href="http://java.sun.com/docs/books/jls/third_edition/html/memory.html">
-Chapter 17 of the Java Language Specification</a> defines the
-<i>happens-before</i> relation on memory operations such as reads and
-writes of shared variables.  The results of a write by one thread are
-guaranteed to be visible to a read by another thread only if the write
-operation <i>happens-before</i> the read operation.  The
-{@code synchronized} and {@code volatile} constructs, as well as the
-{@code Thread.start()} and {@code Thread.join()} methods, can form
-<i>happens-before</i> relationships. In particular:
-
-<ul>
-  <li>Each action in a thread <i>happens-before</i> every action in that
-  thread that comes later in the program's order.
-
-  <li>An unlock ({@code synchronized} block or method exit) of a
-  monitor <i>happens-before</i> every subsequent lock ({@code synchronized}
-  block or method entry) of that same monitor. And because
-  the <i>happens-before</i> relation is transitive, all actions
-  of a thread prior to unlocking <i>happen-before</i> all actions
-  subsequent to any thread locking that monitor.
-
-  <li>A write to a {@code volatile} field <i>happens-before</i> every
-  subsequent read of that same field. Writes and reads of
-  {@code volatile} fields have similar memory consistency effects
-  as entering and exiting monitors, but do <em>not</em> entail
-  mutual exclusion locking.
-
-  <li>A call to {@code start} on a thread <i>happens-before</i> any action in the
-  started thread.
-
-  <li>All actions in a thread <i>happen-before</i> any other thread
-  successfully returns from a {@code join} on that thread.
-
-</ul>
-
-
-The methods of all classes in {@code java.util.concurrent} and its
-subpackages extend these guarantees to higher-level
-synchronization. In particular:
-
-<ul>
-
-  <li>Actions in a thread prior to placing an object into any concurrent
-  collection <i>happen-before</i> actions subsequent to the access or
-  removal of that element from the collection in another thread.
-
-  <li>Actions in a thread prior to the submission of a {@code Runnable}
-  to an {@code Executor} <i>happen-before</i> its execution begins.
-  Similarly for {@code Callables} submitted to an {@code ExecutorService}.
-
-  <li>Actions taken by the asynchronous computation represented by a
-  {@code Future} <i>happen-before</i> actions subsequent to the
-  retrieval of the result via {@code Future.get()} in another thread.
-
-  <li>Actions prior to "releasing" synchronizer methods such as
-  {@code Lock.unlock}, {@code Semaphore.release}, and
-  {@code CountDownLatch.countDown} <i>happen-before</i> actions
-  subsequent to a successful "acquiring" method such as
-  {@code Lock.lock}, {@code Semaphore.acquire},
-  {@code Condition.await}, and {@code CountDownLatch.await} on the
-  same synchronizer object in another thread.
-
-  <li>For each pair of threads that successfully exchange objects via
-  an {@code Exchanger}, actions prior to the {@code exchange()}
-  in each thread <i>happen-before</i> those subsequent to the
-  corresponding {@code exchange()} in another thread.
-
-  <li>Actions prior to calling {@code CyclicBarrier.await}
-  <i>happen-before</i> actions performed by the barrier action, and
-  actions performed by the barrier action <i>happen-before</i> actions
-  subsequent to a successful return from the corresponding {@code await}
-  in other threads.
-
-</ul>
-
-@since 1.5
-
-</body> </html>