Throw ClassNotFoundException for missing class resource in ThrowawayClassLoader

[junhyeong9812]

Overview

ThrowawayClassLoader.loadClass can currently return null, which violates
the ClassLoader.loadClass contract (it must return a non-null Class or
throw ClassNotFoundException). This change makes the fallback path honor the
contract.

Note: I found this while working on #36933 (closing the class-resource
InputStream in the same class). Since #36933 has already been triaged into
the 7.1.0-M1 milestone, I kept it focused and split this contract fix into a
separate PR rather than expanding the accepted one. The two changes touch
different lines of loadClassFromResource and are independent.

Problem

loadClass(name, resolve) delegates to super.loadClass(name, true) and, on
ClassNotFoundException, falls back to loadClassFromResource(name):

catch (ClassNotFoundException ex) {
    return loadClassFromResource(name);
}

loadClassFromResource returns null when the .class resource is not
available:

InputStream inputStream = this.resourceLoader.getResourceAsStream(resourceName);
if (inputStream == null) {
    return null;
}

So loadClass returns null when both the standard delegation and the
resource fallback fail to find the class. The caller
PreComputeFieldFeature.provideFieldValue immediately dereferences the result:

Class<?> throwawayClass = this.throwawayClassLoader.loadClass(field.getDeclaringClass().getName());
Field throwawayField = throwawayClass.getDeclaredField(field.getName()); // NPE when null

Fix

Re-throw the original ClassNotFoundException when the resource fallback yields
no class, so loadClass never returns null:

catch (ClassNotFoundException ex) {
    Class<?> loadedFromResource = loadClassFromResource(name);
    if (loadedFromResource == null) {
        throw ex;
    }
    return loadedFromResource;
}

The original exception is preserved because it carries the most accurate
delegation-failure detail; the resource fallback only confirms there is no
class-byte resource to define.

Note on impact

This is primarily a contract-correctness and diagnostics fix, not a crash fix.
The NullPointerException in PreComputeFieldFeature is caught by a broad
catch (Throwable) that falls back to runtime evaluation of the field, so the
build does not fail today. The observable improvement is twofold:

1. loadClass honors the documented ClassLoader contract.
2. The verbose build-time diagnostic now reports a meaningful
   ClassNotFoundException (with the class name) instead of a confusing
   NullPointerException.

The trigger is narrow: it requires a declaring class whose .class resource is
not resolvable (e.g. a runtime-generated class) that also cannot be loaded via
delegation.

Tests

Added ThrowawayClassLoaderTests.loadClassThrowsClassNotFoundExceptionWhenClassResourceIsMissing,
which drives loadClass through the fallback with a resource loader that
returns no class bytes and asserts that ClassNotFoundException is thrown
(previously loadClass returned null). ./gradlew :spring-core:test and
checkstyleMain/checkstyleTest pass.

[sbrannen]

Please rebase on main and force push your changes to the PR.

[junhyeong9812]

Thanks for taking a look, @sbrannen! I've rebased onto the latest main and force-pushed. Since #36933 was already merged, the only conflict was in the test class, which I resolved by keeping both tests. The loadClass fix in this PR is independent of that change, so it sits cleanly on top.

Please let me know if anything else is needed. Thanks again for your time!

[sbrannen]

This has been merged into main in 233e7b9 and slightly revised in 7b31e0c.

Thanks