Skip to content

[EPIC] Minimize version-specific production classes #15821

Description

@gerashegalov

Goal

Minimize production code that is compiled or packaged as Spark-version-specific when it can safely use a conventional root-jar layout.

This issue replaces the former umbrella PR #14834 as the durable tracker for the gradual unshimming work. It also advances #11926 by reducing the surface that would need generated version-specific package names.

Motivation

The parallel-world classloader remains necessary for code that depends on incompatible Spark APIs or ABI shapes, but treating common code as version-specific by default has costs:

  • root-loaded integrations can fail when helpers are only visible through the shim classloader;
  • the distribution contains unnecessary parallel-world copies;
  • debugging and class ownership are harder to reason about; and
  • adding a Spark shim rebuilds and republishes code that is not actually version-dependent.

Approach

  • Move stable helper surfaces into narrowly-scoped Maven modules whose classes are safe in the jar root.
  • Use binary identity and dependency analysis to verify root safety across supported shims.
  • Replace temporary per-class root-promotion entries with module-level ownership or conditional root-safe source selection.
  • Keep code version-specific when a supported Spark or integration release lacks the required API, or when commonizing it would require reflection or a broader compatibility design.
  • Land the migration as reasonably-sized, independently validated PRs rather than recreating the monolithic change from Minimize the amount of version-specific classes [databricks] #14834.

Completed foundations

Completed milestone: all current Iceberg package-private callers are root-safe

#15905 moved every current cuDF Plugin class that directly accesses an Iceberg package-private class or member to the assembled JAR root. Its package-phase audit now preserves that invariant across every selected Spark/Iceberg runtime world and rejects future callers placed in spark-shared or a versioned shim directory.

This removes the known classloader/package-identity exposure and turns the requirement into a build invariant. Iceberg code that genuinely depends on version-specific public APIs may still remain in its corresponding shim world.

Current priority milestone: eliminate Iceberg classes from spark-shared

#15944 is a draft stacked on #15841. When the stack merges, the assembled distribution for the supported OSS shim matrix should contain no Iceberg classes under spark-shared: portable classes will appear once at the conventional JAR root, while classes with real Spark/Iceberg compatibility differences will remain in the appropriate version-specific directories.

The final step also removes the remaining Iceberg per-class promotion exceptions and handles helpers such as GpuSparkPlanningUtil and GpuBaseReader whose root safety applies only to a subset of supported Spark/Iceberg combinations.

Remaining work

Completion criteria

  • Stable production helpers no longer live under version-specific source roots or spark-shared solely because of build layout.
  • Root-safe module classes appear exactly once at the jar root and do not retain parallel-world copies.
  • Remaining version-specific production classes have a concrete Spark/integration API or ABI reason to stay shimmed.
  • Temporary per-class promotion lists are minimized and contain documented exceptions only.
  • Packaging and compatibility checks pass across supported Spark, Scala, Databricks, Delta Lake, and Iceberg combinations affected by each migration.

Out of scope

  • Eliminating the shim layer entirely.
  • Commonizing code through reflection solely to force bytecode identity.
  • Migrating version-specific test sources unless needed to validate a production-code move.

Activity

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

Metadata

Metadata

Assignees

Labels

epicIssue that encompasses a significant feature or body of work

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions