[GLUTEN-12225][CORE] Fix arrow.c shading: exclude memory/vector packages so public API stays unshaded#12226
Open
sezruby wants to merge 2 commits into
Open
[GLUTEN-12225][CORE] Fix arrow.c shading: exclude memory/vector packages so public API stays unshaded#12226sezruby wants to merge 2 commits into
sezruby wants to merge 2 commits into
Conversation
…API stays unshaded The bundled Arrow C-Data classes (org.apache.arrow.c.*) are correctly excluded from relocation because their native JNI binds to the original class names. However, their public API signatures take and return org.apache.arrow.memory.* and org.apache.arrow.vector.* types, which were being relocated to org.apache.gluten.shaded.*. The result: bundled ArrowArrayStream/ArrowSchema/ArrowArray/Data classes are compiled against the shaded BufferAllocator/VectorSchemaRoot, so any caller passing a vanilla Apache Arrow allocator gets NoSuchMethodError. Triggered for any Spark workload that combines gluten with another library using Arrow C-Data (Iceberg's Arrow vector layer, Lance Java's writer, Snowflake JDBC's Arrow result decoder, etc.) when gluten's bundle wins classloader resolution against vanilla Arrow. Fix: extend the relocation excludes to also keep org.apache.arrow.memory.** and org.apache.arrow.vector.** unshaded. The bundled C-Data API now matches the public Apache Arrow API. Adds dev/check-arrow-c-shading.sh which runs javap on the produced bundle jar and asserts that public method signatures reference unshaded Arrow types. Wired into package/pom.xml's verify phase via exec-maven-plugin so regressions are caught in CI. Tested against the upstream gluten-velox-bundle-spark3.5_2.12-linux_amd64-1.6.0.jar — script exits 1 with a clear diagnosis on the broken bundle. Closes apache#12225
Author
Member
|
@sezruby, thanks for the PR. This fix makes sense. I recall there's a related issue that occurs at compile time when an external project introduces the Gluten JAR as a dependency: a Scala type mismatch caused by the Maven Shade Plugin not rewriting ScalaSignature annotations. My understanding is this PR also fixes that case (see https://chungmin.hashnode.dev/unraveling-a-scala-type-mismatch-mystery). One small concern is potential Arrow version conflicts, since these packages are no longer shaded. That said, the memory and vector APIs should be stable across minor versions, so I assume the risk should be low in practice. |
philo-he
approved these changes
Jun 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Extend
package/pom.xml'sorg.apache.arrowrelocation excludes to also keeporg.apache.arrow.memory.**andorg.apache.arrow.vector.**unshaded.The bundled Arrow C-Data classes (
org.apache.arrow.c.*) are correctly excluded from relocation because their native JNI binds to the original class names. However, their public API signatures take and returnorg.apache.arrow.memory.*andorg.apache.arrow.vector.*types — which were being relocated. The result: the bundledArrowArrayStream/ArrowSchema/ArrowArray/Dataclasses get compiled against the shadedBufferAllocator/VectorSchemaRoot, so any caller passing a vanilla Apache Arrow allocator hitsNoSuchMethodError.This affects any Spark workload that combines gluten with another library using Arrow C-Data (Iceberg's Arrow vector layer, Lance Java's writer, Snowflake JDBC's Arrow result decoder, etc.) when gluten's bundle wins classloader resolution against vanilla Arrow.
How was this patch tested?
Adds
dev/check-arrow-c-shading.shwhich runsjavapon the produced bundle jar and asserts that public method signatures reference unshaded Arrow types. Wired intopackage/pom.xml'sverifyphase viaexec-maven-pluginso regressions are caught in CI.Tested against the upstream
gluten-velox-bundle-spark3.5_2.12-linux_amd64-1.6.0.jar:After applying the relocation exclude change, a freshly-built bundle should pass the same check (script exits 0). The repro from #12225 (3 lines calling
ArrowArrayStream.allocateNew(new RootAllocator(...))) goes fromNoSuchMethodErrortoOK.Closes
#12225