Skip to content

[SPARK-56488][BUILD][3.5] Bump Scala 2.13 to 2.13.9 on branch-3.5#55394

Open
devin-petersohn wants to merge 1 commit intoapache:branch-3.5from
devin-petersohn:spark-56488-scala-2.13.9
Open

[SPARK-56488][BUILD][3.5] Bump Scala 2.13 to 2.13.9 on branch-3.5#55394
devin-petersohn wants to merge 1 commit intoapache:branch-3.5from
devin-petersohn:spark-56488-scala-2.13.9

Conversation

@devin-petersohn
Copy link
Copy Markdown
Contributor

@devin-petersohn devin-petersohn commented Apr 17, 2026

What changes were proposed in this pull request?

Bump Scala 2.13 from 2.13.8 to 2.13.9 to fix CVE-2022-36944 (CVSS 9.8). Includes build fixes required for 2.13.9 compatibility: clearing maven.compiler.target to avoid -release 8 from scala-maven-plugin, removing deprecated -target:jvm-1.8, and fixing StringBuilder.append overload ambiguity.

Why are the changes needed?

To fix CVE-2022-36944.

Does this PR introduce any user-facing change?

Yes. Users building with the -Pscala-2.13 profile will now use Scala 2.13.9 instead of 2.13.8.

How was this patch tested?

Compilation verified with both Scala 2.12 and 2.13.

Was this patch authored or co-authored using generative AI tooling?

Generated by: Claude Opus 4.6

Bump the Scala 2.13 profile from 2.13.8 to 2.13.9 to address
CVE-2022-36944 (critical deserialization vulnerability, CVSS 9.8).

Changes in the scala-2.13 Maven profile:
- Bump scala.version from 2.13.8 to 2.13.9
- Clear maven.compiler.source/target to prevent scala-maven-plugin 4.8.0
  from auto-converting the inherited target=1.8 into scalac -release 8,
  which uses ct.sym and hides sun.* packages needed at compile time
- Remove deprecated -target:jvm-1.8 scalac flag

Fix StringBuilder.append overload ambiguity introduced in Scala 2.13.9
by using explicit lambdas instead of eta-expanded method references in
ShowCreateTableExec.scala and tables.scala.

Co-Authored-By: Claude <noreply@anthropic.com>
Copy link
Copy Markdown
Member

@dongjoon-hyun dongjoon-hyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but -1 because Scala language version change is a breaking change.

@dongjoon-hyun dongjoon-hyun changed the title [SPARK-56488][BUILD] Bump Scala 2.13 to 2.13.9 on branch-3.5 [SPARK-56488][BUILD][3.5] Bump Scala 2.13 to 2.13.9 on branch-3.5 Apr 17, 2026
@dongjoon-hyun
Copy link
Copy Markdown
Member

cc @holdenk

@holdenk
Copy link
Copy Markdown
Contributor

holdenk commented Apr 17, 2026

Oh awesome, yeah I was talking with @devin-petersohn about this, thanks for making the PR so fast!

@holdenk
Copy link
Copy Markdown
Contributor

holdenk commented Apr 17, 2026

What about if we added a new profile for the newer Scala version? That way we can release binary compat version, but if anyone is worried about this they can build with the different profile?

@dongjoon-hyun
Copy link
Copy Markdown
Member

dongjoon-hyun commented Apr 17, 2026

Scala version change has been very notorious at every maintenance version in the Apache Spark community. I don't think we can set up to build a new set of CIs for that new profile (including Scala/PySpark/SparkR) to guarantee. It requires really tremendous efforts to keep the promise. Let's not to give a misleading signal.

@holdenk
Copy link
Copy Markdown
Contributor

holdenk commented Apr 17, 2026

I see what you mean about not wanting the CI overhead and verification overhead. Let me think about this over the weekend and see if I can come up with another workaround that would let us do both, otherwise maybe given it's only on Scala deser it's an ok / non exploitable CVE.

@dongjoon-hyun
Copy link
Copy Markdown
Member

If there is no code change, it would be easier to us to support because a user may change scala.version during their building. According to this PR, the code change seems to be required which means a non-trivial update.

@dongjoon-hyun
Copy link
Copy Markdown
Member

IIRC, the Apache Spark community never takes a risk to change Scala language version in the maintenance releases, @holdenk .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants