apache/cassandra · error · InvalidRequestException

Java UDF validation failed:

Error message

Java UDF validation failed: 

What it means

After compiling a Java UDF, the bytecode verifier scans the class for dangerous constructs (reflection, thread ops, I/O, static fields, etc.). If disallowed constructs are found, JavaBasedUDFunction throws this InvalidRequestException listing the violations. It means the UDF body compiled but uses operations the UDF sandbox forbids.

Source

Thrown at src/java/org/apache/cassandra/cql3/functions/JavaBasedUDFunction.java:330

                if (fullSource)
                    throw new InvalidRequestException("Java source compilation failed:\n" + problems + "\n generated source:\n" + javaSource);
                else
                    throw new InvalidRequestException("Java source compilation failed:\n" + problems);
            }

            // Verify the UDF bytecode against use of probably dangerous code
            Set<String> errors = udfByteCodeVerifier.verify(targetClassName, targetClassLoader.classData(targetClassName));
            String validDeclare = "not allowed method declared: " + executeInternalName + '(';
            for (Iterator<String> i = errors.iterator(); i.hasNext();)
            {
                String error = i.next();
                // we generate a random name of the private, internal execute method, which is detected by the byte-code verifier
                if (error.startsWith(validDeclare))
                    i.remove();
            }
            if (!errors.isEmpty())
                throw new InvalidRequestException("Java UDF validation failed: " + errors);

            // Load the class and create a new instance of it
            Thread thread = Thread.currentThread();
            ClassLoader orig = thread.getContextClassLoader();
            try
            {
                thread.setContextClassLoader(UDFunction.udfClassLoader);
                // Execute UDF intiialization from UDF class loader

                Class cls = Class.forName(targetClassName, false, targetClassLoader);

                // Count only non-synthetic methods, so code coverage instrumentation doesn't cause a miscount
                int nonSyntheticMethodCount = 0;
                for (Method m : cls.getDeclaredMethods())
                {
                    if (!m.isSynthetic())
                    {
                        nonSyntheticMethodCount += 1;

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Remove the forbidden constructs listed after 'Java UDF validation failed:' (e.g. Thread, reflection, static fields, I/O).
  2. Keep the UDF body pure computation over its arguments and return value only.
  3. Compute side effects in the application layer, not the UDF.
  4. Drop and recreate the function after cleaning the body; consult UDFByteCodeVerifier for the disallowed list.

Example fix

// before
' Thread t = Thread.currentThread(); return x + 1; '
// after
' return x + 1; '
Defensive patterns

Strategy: validation

Validate before calling

// pre-scan body for sandbox-forbidden tokens before DDL:
Set<String> forbidden = Set.of("Thread","Class","forName","System.","File","Runtime","reflect","static");
for (String tok : forbidden) if (body.contains(tok)) throw new IllegalArgumentException("UDF body uses forbidden construct: " + tok);

Try / catch

try { session.execute(createFunctionDdl); } catch (InvalidRequestException e) { if (e.getMessage().contains("Java UDF validation failed")) { /* remove listed forbidden constructs and re-CREATE */ } else throw e; }

Prevention

When it happens

Trigger: CREATE FUNCTION whose Java body references Thread.currentThread(), classloading, reflection, static mutable state, I/O, or other constructs flagged by UDFByteCodeVerifier; the generated execute method has an unexpected signature (though the internal-name mismatch is filtered out).

Common situations: Porting normal Java code (logging, I/O, caching in statics) into UDFs; calling Cassandra/driver APIs from a UDF; trying multithreading or System calls inside UDFs.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/f63a70f3a4c5651c. Report an issue: GitHub.