This is an automated email from the ASF dual-hosted git repository.

HyukjinKwon pushed a commit to branch branch-4.x
in repository https://gitbox.apache.org/repos/asf/spark.git


The following commit(s) were added to refs/heads/branch-4.x by this push:
     new caa929b8db0a [SPARK-57610][SQL][TEST] Tolerate null 
ArithmeticException message in TruncTimestamp overflow test on JDK 25
caa929b8db0a is described below

commit caa929b8db0a6f9a68c773593b156b8424354b2b
Author: Hyukjin Kwon <[email protected]>
AuthorDate: Tue Jun 23 12:43:56 2026 +0900

    [SPARK-57610][SQL][TEST] Tolerate null ArithmeticException message in 
TruncTimestamp overflow test on JDK 25
    
    ### What changes were proposed in this pull request?
    
    `DateExpressionsSuite` "TruncTimestamp of Long.MinValue overflows with 
ArithmeticException"
    fails under JDK 25 in codegen mode. The overflow `ArithmeticException` IS 
thrown (from
    `Math.*Exact` in `DateTimeUtils.truncTimestamp`), but under JDK 25 the JIT 
"hot-throw"
    optimization can deliver it with a `null` message (a pre-allocated 
exception), whereas the
    interpreter reports `"long overflow"`. The old assertion checked the 
message and so failed on
    JDK 25 (`Expected ... but null error message found`).
    
    This makes the test assert the exception TYPE (`ArithmeticException`) 
across both the
    interpreted and codegen paths and tolerate a `null` message (the JDK 25 
hot-throw case),
    which is not part of the API contract. See SPARK-55714 / SPARK-55755 / 
JDK-8367990.
    
    ### Why are the changes needed?
    
    The scheduled `Build / Java 25` (and `maven_java25`) builds fail on this 
catalyst test. It is a
    JDK-version-dependent exception-message difference, not a Spark logic 
change: the exception is
    still thrown, only its message varies.
    
    ### Does this PR introduce _any_ user-facing change?
    
    No. Test-only change.
    
    ### How was this patch tested?
    
    Validated under real JDK 25 codegen: the catalyst job
    (`api, catalyst, hive-thriftserver`) passed in the combined Build/Java25 
fork run that includes
    this fix (alongside the sibling log4j 2.26.0 and try_arithmetic golden 
fixes):
    https://github.com/HyukjinKwon/spark/actions/runs/27943439418
    
    **Validated GREEN on the fork:** the identical fix on branch-4.2 made the 
`Build (branch-4.2, Scala 2.13, JDK 25)` build green incl. the catalyst job: 
https://github.com/HyukjinKwon/spark/actions/runs/27942948687
    (The unfixed test is JIT-intermittent on JDK 25 - passes some runs, fails 
others; this fix removes the flakiness by tolerating the null hot-throw 
message.)
    
    ### Was this patch authored or co-authored using generative AI tooling?
    
    Generated-by: Claude Code (Opus 4.8)
    
    Closes #56666 from HyukjinKwon/ci-fix/trunctimestamp-jdk25.
    
    Authored-by: Hyukjin Kwon <[email protected]>
    Signed-off-by: Hyukjin Kwon <[email protected]>
    (cherry picked from commit cf01b203fefcbd2b3e61db5a40c54bc897f99a47)
    Signed-off-by: Hyukjin Kwon <[email protected]>
---
 .../sql/catalyst/expressions/DateExpressionsSuite.scala   | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git 
a/sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala
 
b/sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala
index d6b18a9370e0..869cac60d7c6 100644
--- 
a/sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala
+++ 
b/sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala
@@ -862,8 +862,19 @@ class DateExpressionsSuite extends SparkFunSuite with 
ExpressionEvalHelper {
       val minTimestamp = Literal.create(Long.MinValue, TimestampType)
       Seq("YEAR", "QUARTER", "MONTH", "WEEK", "DAY", "HOUR", "MINUTE",
           "SECOND", "MILLISECOND").foreach { fmt =>
-        checkExceptionInExpression[ArithmeticException](
-          TruncTimestamp(Literal.create(fmt, StringType), minTimestamp), "")
+        // The overflow surfaces as a raw `ArithmeticException` from 
`Math.*Exact`, which
+        // `checkEvaluation` wraps in a scalatest `TestFailedException`. 
Unwrap it via `getCause`
+        // and assert the type. The exception message is not part of the API 
contract: JDK 25 may
+        // throw it with a `null` message in codegen mode (JIT "hot throw", 
see SPARK-55714 /
+        // SPARK-55755 / JDK-8367990), while the interpreter reports "long 
overflow", so tolerate
+        // a null message. Mirrors the `TimestampAddInterval` overflow check 
in this suite.
+        val e = intercept[Exception] {
+          checkEvaluation(
+            TruncTimestamp(Literal.create(fmt, StringType), minTimestamp),
+            null)
+        }.getCause
+        assert(e.isInstanceOf[ArithmeticException])
+        assert(e.getMessage == null || e.getMessage.contains("overflow"))
       }
     }
   }


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

Reply via email to