diff options
| author | bryce <bryce@138bc75d-0d04-0410-961f-82ee72b054a4> | 2000-10-30 01:51:34 +0000 |
|---|---|---|
| committer | bryce <bryce@138bc75d-0d04-0410-961f-82ee72b054a4> | 2000-10-30 01:51:34 +0000 |
| commit | ad5c72752be9904d6abb518ba900821c4b23f397 (patch) | |
| tree | 223576160418ba3d5267dc85b9ee15df44965d20 | |
| parent | 38fca3fc1d15e9a8b3efd8905cc429b1ec0c244f (diff) | |
| download | gcc-ad5c72752be9904d6abb518ba900821c4b23f397.tar.gz | |
2000-10-30 Bryce McKinlay <bryce@albatross.co.nz>
* java/util/BitSet.java: Updated @specnote.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@37138 138bc75d-0d04-0410-961f-82ee72b054a4
| -rw-r--r-- | libjava/ChangeLog | 4 | ||||
| -rw-r--r-- | libjava/java/util/BitSet.java | 17 |
2 files changed, 10 insertions, 11 deletions
diff --git a/libjava/ChangeLog b/libjava/ChangeLog index 3a58979fe30..be1a10a1107 100644 --- a/libjava/ChangeLog +++ b/libjava/ChangeLog @@ -1,3 +1,7 @@ +2000-10-30 Bryce McKinlay <bryce@albatross.co.nz> + + * java/util/BitSet.java: Updated @specnote. + 2000-10-29 Bryce McKinlay <bryce@albatross.co.nz> * java/util/AbstractCollection.java (addAll): Use size() instead of diff --git a/libjava/java/util/BitSet.java b/libjava/java/util/BitSet.java index 5a2dd44e6f9..fa0f3a13e88 100644 --- a/libjava/java/util/BitSet.java +++ b/libjava/java/util/BitSet.java @@ -33,17 +33,12 @@ import java.io.Serializable; * while another thread is simultaneously modifying it, the results are * undefined. * - * @specnote There is some confusion as to whether or not this class should - * be synchronized. JDK 1.1 javadocs explicitly state that the - * class is NOT synchronized, however the code listed in the JDK 1.3 - * javadoc for the hashCode() method implies that it is. It is not - * stated elsewhere in the 1.2 javadoc that the class is - * synchronized, unlike Hashtable and Vector. From an efficiency - * perspective, it is very undesirable to synchronize this class - * because multiple locks and explicit lock ordering are required - * to safely synchronize some methods. For this reason we're going - * with the unsynchronized implementation unless the specs are - * changed to explicitly say otherwise. + * @specnote Historically, there has been some confusion as to whether or not + * this class should be synchronized. From an efficiency perspective, + * it is very undesirable to synchronize it because multiple locks + * and explicit lock ordering are required to safely synchronize some + * methods. The JCL 1.2 supplement book specifies that as of JDK + * 1.2, the class is no longer synchronized. * * @author Jochen Hoenicke * @author Tom Tromey <tromey@cygnus.com> |