RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock for non-parallel capable loader [v3]

[Alan Bateman]

On Fri, 30 Jun 2023 18:12:18 GMT, Mandy Chung <mchung at 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