Fast-path copyToTempDirectory via ClassLoader.getResourceAsStream

[skylightis666]

Problem

ResourceLoader.copyToTempDirectory(path, class) finds the JAR
containing class and then calls extractFilesOrFoldersFromJar →
unzip(jarPath, tempDir), which unzips the ENTIRE host JAR just to
locate a single resource (e.g. mac_arm/libsodium.dylib).

For small dependency JARs this is fine. For fat / uberjars common in
Spring Boot, AWS Lambda, or Clojure deployments (~100k–150k entries,
300–800 MB), the unzip is O(N) in total entry count and adds
10–20 seconds of pure I/O to cold start, every time the host
application boots — even though only a single file is actually needed.

Profile via JFR / jstack while booting a host app that depends on
lazysodium-java:

com.goterl.resourceloader.ResourceLoader.unzipFiles
com.goterl.resourceloader.ResourceLoader.unzip
com.goterl.resourceloader.ResourceLoader.extractFilesOrFoldersFromJar
com.goterl.resourceloader.ResourceLoader.extractFromWithinAJarFile
com.goterl.resourceloader.ResourceLoader.copyToTempDirectory
com.goterl.resourceloader.SharedLibraryLoader.load
com.goterl.lazysodium.utils.LibraryLoader.loadBundledLibrary
com.goterl.lazysodium.SodiumJava.<init>

Measured impact

SodiumJava constructor wall-time on macOS arm64 / APFS / Java 25,
measured by instantiating the class with the unpatched vs patched
resource-loader first on the classpath of the same host uberjar:

Host classpath	Before	After
Minimal (3 jars)	552 ms	~80 ms
Real Clojure uberjar (138k entries, 321 MB)	18 679 ms	522 ms

The 19→0.5 s reduction matches almost exactly the size of the unzip
step in the profile.

Fix

Add a fast path at the top of copyToTempDirectory: if the JVM's
standard ClassLoader.getResource(name) returns a non-null,
non-directory resource, stream it to a temp file in O(1) and return.
The legacy extraction path is preserved as the fallback for:

• nested-jar layouts where getResource returns null (e.g. Spring Boot
  loader's BOOT-INF/lib/<inner>.jar!/... — same scenario PRs Make lazysodium-java work in a stand-alone spring boot jar #5 and
  Fix for #18 nested jar syntax support #19 were targeting),
• directory resources, which the legacy path handles via
  copyDirectory (explicitly excluded from the fast path so
  FileLoaderTest.loadWholeFolders and friends keep working).

The new code lives in a small private helper tryFastPath(...) to keep
the public method readable.

Behavioural notes

• Output shape is unchanged: a single file inside a fresh temp
  directory whose absolute path is returned.
• Permissions: Files.copy preserves read/write defaults; the existing
  writePerms / readPerms / execPerms collections are only used in
  the legacy unzip path, where they continue to apply.
• Directory resources are explicitly excluded from the fast path
  (URL ends with /, or file:// URL points to a directory).

Tests

• All 16 existing tests continue to pass.
• 2 new parametrised tests cover the fast path for both test1.txt
  and /test1.txt relative paths (verifies non-null, isFile, correct
  filename, non-empty contents).
• loadWholeFolders (directory case) still passes, confirming the
  fast path is correctly bypassed for directories.

BUILD SUCCESSFUL in 7s
18 tests completed, 0 failures