peter-toth opened a new pull request, #57130:
URL: https://github.com/apache/spark/pull/57130

   ### What changes were proposed in this pull request?
   
   `DataTypeProtoConverter.toCatalystUDT` deserializes a client-supplied 
`DataType.UDT` proto. When the UDT carries a `jvm_class`, it loaded and 
instantiated that class with 
`classForName(jvmClass).getConstructor().newInstance()` and only then relied on 
the (erased) cast to `UserDefinedType[_]`. So the class's no-arg constructor - 
and, because `classForName` defaults to `initialize = true`, its static 
initializers - ran before any type check, and a `jvm_class` that is not a 
`UserDefinedType` produced a `ClassCastException` after the fact.
   
   This change loads the class without initializing it, checks 
`classOf[UserDefinedType[_]].isAssignableFrom(clazz)` first, and throws a clear 
`InvalidPlanInput` (`CONNECT_INVALID_PLAN.UDT_JVM_CLASS_NOT_UDT`) if it is not 
a `UserDefinedType`. A valid UDT is instantiated exactly as before.
   
   ### Why are the changes needed?
   
   Only a class that is actually a `UserDefinedType` should be instantiated 
when converting a UDT proto. Checking the type first gives a clear error for an 
invalid `jvm_class` instead of a `ClassCastException`, and avoids running the 
constructor/static initializer of an unrelated class named in the request.
   
   ### Does this PR introduce _any_ user-facing change?
   
   Yes, a small error change: an invalid non-UDT `jvm_class` in a 
`DataType.UDT` now raises `CONNECT_INVALID_PLAN.UDT_JVM_CLASS_NOT_UDT` instead 
of a `ClassCastException`.
   
   ### How was this patch tested?
   
   New test in `InvalidInputErrorsSuite` asserting a non-UserDefinedType 
`jvm_class` raises `CONNECT_INVALID_PLAN.UDT_JVM_CLASS_NOT_UDT`.
   
   ### Was this patch authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Code (Opus 4.8)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to