Package dev.frostlake.executor.udf

Class JarHandlerLoader

java.lang.Object
dev.frostlake.executor.udf.JarHandlerLoader
public final class JarHandlerLoader extends Object
Loads a pre-compiled handler class from the JAR(s) named in a UDF/procedure's IMPORTS clause — the alternative to an inline AS $$ … $$ body. Language-agnostic: Java and Scala both compile to JVM classes, so a Scala object/class in a JAR loads exactly like a Java class (the per-language executors keep their own handler-invocation logic, e.g. a Scala object's MODULE$ or a procedure's Snowpark Session arg).

Each IMPORTS entry is resolved to a local file:

  • s3://bucket/key.jar — mapped to a local path by the engine's S3PathResolver (configured via stage.s3.localMappings / stage.s3.localRoot).
  • @stage/path.jar — the named stage is looked up in the catalog; an S3-backed stage maps through the resolver and a file:// stage uses its local directory. Unknown stages (or @~/@% user/table stages) fall back to treating the reference as a local path with a leading @ stripped, preserving prior behavior.
  • a bare path — used as-is.
A stage-resolved import additionally puts every other *.jar in the same stage directory on the classpath (imports first, then siblings sorted by name). Handler JARs are usually thin — on Snowflake their dependencies arrive via the PACKAGES transitive closure, which the engine cannot resolve from Maven — so the stage directory doubles as the function's dependency set: drop the missing dependency JARs beside the handler JAR and they link. Loading is child-first (see ChildFirstUdfClassLoader): the jar's own dependency versions win over the engine's classpath, while JDK/engine/Snowpark/SLF4J classes stay shared so handlers can reference them. See docs/functions.md.

  • Method Details

    • load

      public static Class<?> load(List<String> imports, String className, Catalog catalog, S3PathResolver s3Resolver)
      Load className (trying the Scala object singleton className$ first) from the IMPORTS jar(s).