Skip to content

Commit ef30bd6

Browse files
chore(syncmap): fix javadoc for the SyncMap class
1 parent a467b3c commit ef30bd6

File tree

1 file changed

+2
-3
lines changed
  • collections/src/main/java/space/vectrix/collections

1 file changed

+2
-3
lines changed

collections/src/main/java/space/vectrix/collections/SyncMap.java

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,6 @@
3333
import java.util.NoSuchElementException;
3434
import java.util.Objects;
3535
import java.util.Set;
36-
import java.util.concurrent.ConcurrentHashMap;
3736
import java.util.concurrent.ConcurrentMap;
3837
import java.util.concurrent.atomic.LongAdder;
3938
import java.util.function.BiConsumer;
@@ -48,7 +47,7 @@
4847

4948
/**
5049
* Represents a hash table capable of highly concurrent retrievals and updates.
51-
* It works similarly to {@link ConcurrentHashMap} and
50+
* It works similarly to {@link java.util.concurrent.ConcurrentHashMap} and
5251
* shares many of the same concepts. However, the main difference is with how
5352
* this map carefully manages two separate tables. One table is immutable
5453
* providing efficient retrieval and updates of existing and frequently
@@ -58,7 +57,7 @@
5857
* <p>This map is optimized for cases where updates and retrievals for existing
5958
* entries is a lot faster than recently added entries. However, the
6059
* performance in other cases are close or equal to that of {@link
61-
* ConcurrentHashMap} which is faster than a traditional
60+
* java.util.concurrent.ConcurrentHashMap} which is faster than a traditional
6261
* map paired with a read and write lock, or maps with an exclusive lock (such
6362
* as using {@link Collections#synchronizedMap(Map)}) in similar scenarios.</p>
6463
*

0 commit comments

Comments
 (0)