Fix inconsistent ClassLoader usage between class presence check and actual class loading

[linw-bai]

Fix inconsistent ClassLoader usage between class presence check and actual class loading

Background

LettuceClassUtils#getDefaultClassLoader() currently returns the Thread Context ClassLoader (TCCL) when available.
However, LettuceClassUtils#isPresent(...) relies on this method to check class existence, while the actual class loading is later performed using the ClassLoader of LettuceClassUtils itself.
This leads to an inconsistent ClassLoader strategy:

• Presence check: uses Thread Context ClassLoader
• Actual loading: uses LettuceClassUtils.class.getClassLoader()
  In environments with multiple ClassLoaders (e.g. OSGi, Servlet containers, shaded applications, plugin systems), this can cause:
• isPresent(...) returning true
• Followed by a ClassNotFoundException during actual class loading
  This is a classic false-positive detection issue caused by mismatched ClassLoaders.

Root Cause

The root problem is that:

• getDefaultClassLoader() returns TCCL
• But Class.forName(...) and direct loading later use a different ClassLoader
  So the class existence check is not aligned with the loader that actually loads the class.

Solution

This PR makes the ClassLoader strategy consistent by:

• Ensuring that both class presence checks and real class loading use the same ClassLoader
• Preferring LettuceClassUtils.class.getClassLoader() as the primary loader

---

Note

Medium Risk
Changes the default ClassLoader selection to always use LettuceClassUtils’ defining loader, which can affect environments that relied on the thread context ClassLoader for resolution. Risk is limited in scope but may alter class discovery/loading behavior in modular/container setups.

Overview
Fixes a mismatch in LettuceClassUtils where isPresent(...) could report a class as available using one ClassLoader while subsequent loading used another.

getDefaultClassLoader() is simplified to always return LettuceClassUtils.class.getClassLoader(), ensuring class presence checks and actual loading use the same loader and avoiding false-positive isPresent(...) results in multi-ClassLoader environments.

^{Written by Cursor Bugbot for commit 3015e7c. This will update automatically on new commits. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}