On Thu, 29 Jun 2023 23:39:55 GMT, Mandy Chung <mch...@openjdk.org> wrote:
> The spec of `ClassLoader::getClassLoadingLock` is unclear that this method is > intended for parallel-capable class loader implementations to provide an > alternate implementation. For non-parallel-capable class loaders, this > method should return this `ClassLoader` object. The javadoc uses "the > default implementation" which could be interpreted that non-parallel-capable > class loaders can also override this implementation, which is not the intent. > See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html. Looks good. One change requested on terminology. Thanks src/java.base/share/classes/java/lang/ClassLoader.java line 656: > 654: * @apiNote > 655: * This method allows parallel capable class loaders to implement > 656: * finer-grained locking scheme such that multiple threads may load > classes s/scheme/schemes/ src/java.base/share/classes/java/lang/ClassLoader.java line 658: > 656: * finer-grained locking scheme such that multiple threads may load > classes > 657: * concurrently without deadlocks. For non-parallel-capable class > loaders, > 658: * the {@code ClassLoader} object is held during the class loading > operations. s/is held/is synchronized on/ - as that is the terminology loadClass uses. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14720#pullrequestreview-1506269248 PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1247270508 PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1247271118
