On Fri, 30 Jun 2023 18:12:18 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. > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > make it implSpec per CSR review feedback src/java.base/share/classes/java/lang/ClassLoader.java line 661: > 659: * concurrently without deadlocks. For non-parallel-capable class > loaders, > 660: * the {@code ClassLoader} object is synchronized on during the > class loading > 661: * operations. Class loaders with non-hierarchical delegation > should be At some point we might want to re-visit the use of "non-hierarchical" (and "hierarchical" in the class description) as deadlocks are also possible with hierarchical delegation when mixing parent-first and child-first delegation. It could be that the the API note provides a strong recommendation the class loader be parallel capable when it is anything other than single parent with parent delegation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1257723627
