move ConcurrentReferenceHashMap back to Envers where it is actually used

Author: gavinking

hibernate-core/src/main/java/org/hibernate/internal/util/collections/ConcurrentReferenceHashMap.java renamed to hibernate-envers/src/main/java/org/hibernate/envers/internal/tools/ConcurrentReferenceHashMap.java

@@ -2,9 +2,10 @@
  * SPDX-License-Identifier: Apache-2.0
  * Copyright Red Hat Inc. and Hibernate Authors
  */
-package org.hibernate.internal.util.collections;
+package org.hibernate.envers.internal.tools;
 
 import java.io.IOException;
+import java.io.Serial;
 import java.io.Serializable;
 import java.lang.ref.Reference;
 import java.lang.ref.ReferenceQueue;
@@ -122,14 +123,15 @@
  * @author Doug Lea
  * @author Jason T. Greene
  */
-public class ConcurrentReferenceHashMap<K, V> extends AbstractMap<K, V>
+class ConcurrentReferenceHashMap<K, V> extends AbstractMap<K, V>
 		implements java.util.concurrent.ConcurrentMap<K, V>, Serializable {
+	@Serial
 	private static final long serialVersionUID = 7249069246763182397L;
 
 	/*
-		 * The basic strategy is to subdivide the table among Segments,
-		 * each of which itself is a concurrently readable hash table.
-		 */
+	 * The basic strategy is to subdivide the table among Segments,
+	 * each of which itself is a concurrently readable hash table.
+	 */
 
 	/**
 	 * An option specifying which Java reference type should be used to refer
@@ -455,42 +457,43 @@ static <K, V> HashEntry<K, V>[] newArray(int i) {
 	 */
 	static final class Segment<K, V> extends ReentrantLock implements Serializable {
 		/*
-				 * Segments maintain a table of entry lists that are ALWAYS
-				 * kept in a consistent state, so can be read without locking.
-				 * Next fields of nodes are immutable (final).  All list
-				 * additions are performed at the front of each bin. This
-				 * makes it easy to check changes, and also fast to traverse.
-				 * When nodes would otherwise be changed, new nodes are
-				 * created to replace them. This works well for hash tables
-				 * since the bin lists tend to be short. (The average length
-				 * is less than two for the default load factor threshold.)
-				 *
-				 * Read operations can thus proceed without locking, but rely
-				 * on selected uses of volatiles to ensure that completed
-				 * write operations performed by other threads are
-				 * noticed. For most purposes, the "count" field, tracking the
-				 * number of elements, serves as that volatile variable
-				 * ensuring visibility.  This is convenient because this field
-				 * needs to be read in many read operations anyway:
-				 *
-				 *   - All (unsynchronized) read operations must first read the
-				 *     "count" field, and should not look at table entries if
-				 *     it is 0.
-				 *
-				 *   - All (synchronized) write operations should write to
-				 *     the "count" field after structurally changing any bin.
-				 *     The operations must not take any action that could even
-				 *     momentarily cause a concurrent read operation to see
-				 *     inconsistent data. This is made easier by the nature of
-				 *     the read operations in Map. For example, no operation
-				 *     can reveal that the table has grown but the threshold
-				 *     has not yet been updated, so there are no atomicity
-				 *     requirements for this with respect to reads.
-				 *
-				 * As a guide, all critical volatile reads and writes to the
-				 * count field are marked in code comments.
-				 */
+		 * Segments maintain a table of entry lists that are ALWAYS
+		 * kept in a consistent state, so can be read without locking.
+		 * Next fields of nodes are immutable (final).  All list
+		 * additions are performed at the front of each bin. This
+		 * makes it easy to check changes, and also fast to traverse.
+		 * When nodes would otherwise be changed, new nodes are
+		 * created to replace them. This works well for hash tables
+		 * since the bin lists tend to be short. (The average length
+		 * is less than two for the default load factor threshold.)
+		 *
+		 * Read operations can thus proceed without locking, but rely
+		 * on selected uses of volatiles to ensure that completed
+		 * write operations performed by other threads are
+		 * noticed. For most purposes, the "count" field, tracking the
+		 * number of elements, serves as that volatile variable
+		 * ensuring visibility.  This is convenient because this field
+		 * needs to be read in many read operations anyway:
+		 *
+		 *   - All (unsynchronized) read operations must first read the
+		 *     "count" field, and should not look at table entries if
+		 *     it is 0.
+		 *
+		 *   - All (synchronized) write operations should write to
+		 *     the "count" field after structurally changing any bin.
+		 *     The operations must not take any action that could even
+		 *     momentarily cause a concurrent read operation to see
+		 *     inconsistent data. This is made easier by the nature of
+		 *     the read operations in Map. For example, no operation
+		 *     can reveal that the table has grown but the threshold
+		 *     has not yet been updated, so there are no atomicity
+		 *     requirements for this with respect to reads.
+		 *
+		 * As a guide, all critical volatile reads and writes to the
+		 * count field are marked in code comments.
+		 */
 
+		@Serial
 		private static final long serialVersionUID = 2249069246763182397L;
 
 		/**
@@ -952,7 +955,7 @@ public ConcurrentReferenceHashMap(
 		identityComparisons = options != null && options.contains( Option.IDENTITY_COMPARISONS );
 
 		for ( int i = 0; i < this.segments.length; ++i ) {
-			this.segments[i] = new Segment<K, V>(
+			this.segments[i] = new Segment<>(
 					cap, loadFactor,
 					keyType, valueType, identityComparisons
 			);
@@ -1642,6 +1645,7 @@ public V nextElement() {
 	 * This class is needed for JDK5 compatibility.
 	 */
 	static class SimpleEntry<K, V> implements Entry<K, V>, Serializable {
+		@Serial
 		private static final long serialVersionUID = -8499721149061103585L;
 
 		private final K key;
@@ -1848,6 +1852,7 @@ public void clear() {
 	 * for each key-value mapping, followed by a null pair.
 	 * The key-value mappings are emitted in no particular order.
 	 */
+	@Serial
 	private void writeObject(java.io.ObjectOutputStream s) throws IOException {
 		s.defaultWriteObject();
 
@@ -1883,6 +1888,7 @@ private void writeObject(java.io.ObjectOutputStream s) throws IOException {
 	 *
 	 * @param s the stream
 	 */
+	@Serial
 	@SuppressWarnings("unchecked")
 	private void readObject(java.io.ObjectInputStream s)
 			throws IOException, ClassNotFoundException {

hibernate-envers/src/main/java/org/hibernate/envers/internal/tools/ReflectionTools.java

@@ -13,7 +13,6 @@
 import org.hibernate.envers.exception.AuditException;
 import org.hibernate.envers.internal.entities.PropertyData;
 import org.hibernate.envers.tools.Pair;
-import org.hibernate.internal.util.collections.ConcurrentReferenceHashMap;
 import org.hibernate.property.access.spi.Getter;
 import org.hibernate.property.access.spi.PropertyAccessStrategy;
 import org.hibernate.property.access.spi.PropertyAccessStrategyResolver;