Motivation

When parsing projects that use Lombok on large classpaths (e.g. Moderne CLI), Lombok's ShadowClassLoader spends hundreds of seconds of CPU during LombokProcessor.init(). The ShadowClassLoader.getResources() method calls isPartOfShadowSuffix() on every jar URL from the parent classloader, which opens each jar as a ZipInputStream and sequentially reads every entry to check for lombok-prefixed paths. On a classpath with many large jars, this is extremely slow.

Stack trace from a jstack sample showing the bottleneck (328s CPU / 384s elapsed):

lombok.launch.ShadowClassLoader.isPartOfShadowSuffixJarBased(ShadowClassLoader.java:384)
lombok.launch.ShadowClassLoader.isPartOfShadowSuffix(ShadowClassLoader.java:428)
lombok.launch.ShadowClassLoader.getResources(ShadowClassLoader.java:462)
lombok.core.SpiLoadUtil.findServices(SpiLoadUtil.java:94)
lombok.core.configuration.ConfigurationKeysLoader$LoaderLoader.loadAllConfigurationKeys

Summary

• Wrap the parent classloader passed to ShadowClassLoader with a ResourceFilteredClassLoader that returns empty results for getResources() / getResource(), while still delegating class loading normally
• This forces the ShadowClassLoader to rely solely on its override jars (set via shadow.override.lombok), which already contain everything Lombok needs (lombok.jar + rewrite-java-lombok)
• The change is entirely contained in LombokSupport.java — no parser modifications needed

Test plan

• rewrite-java-lombok module tests pass
• rewrite-java-25 Lombok-specific tests pass
• All 6 modified/dependent modules compile cleanly
• Verified via jstack that the ShadowClassLoader scanning bottleneck is eliminated — Lombok now proceeds directly to annotation processing