apache/iceberg · error · UnsupportedOperationException

this.getClass().getName() + " doesn't implement addNonDefaul

Error message

this.getClass().getName() + " doesn't implement addNonDefaultSpec()"

What it means

UpdatePartitionSpec.addNonDefaultSpec() is a default method that throws UnsupportedOperationException when the concrete implementation does not support adding a partition spec that is not set as the table's default spec. Like other optional API methods, only implementations that support this behavior override it.

Source

Thrown at api/src/main/java/org/apache/iceberg/UpdatePartitionSpec.java:133

  /**
   * Rename a field in the partition spec.
   *
   * @param name name of the partition field to rename
   * @param newName replacement name for the partition field
   * @return this for method chaining
   * @throws IllegalArgumentException If name doesn't identify a column in the schema or if this
   *     change conflicts with other additions, removals, or renames.
   */
  UpdatePartitionSpec renameField(String name, String newName);

  /**
   * Sets that the new partition spec will be NOT set as the default partition spec for the table,
   * the default behavior is to do so.
   *
   * @return this for method chaining
   */
  default UpdatePartitionSpec addNonDefaultSpec() {
    throw new UnsupportedOperationException(
        this.getClass().getName() + " doesn't implement addNonDefaultSpec()");
  }
}

View on GitHub (pinned to 86d9c8fc54)

Solutions

Use the default-spec update path (apply the new spec as the table's default) instead of addNonDefaultSpec().
Check the implementation class (named in the message) for supported operations before calling optional methods.
Implement addNonDefaultSpec() if you own the UpdatePartitionSpec implementation.
Upgrade Iceberg if support was added in a later version.

Example fix

// before
transaction.updatePartitionSpec().addNonDefaultSpec().addField("day");

// after
transaction.updatePartitionSpec().addField("day"); // default spec update

Defensive patterns

Strategy: try-catch

Validate before calling

// no pre-call check is exposed; consult the implementation's supported operations

Type guard

boolean supportsNonDefaultSpec = update instanceof BaseUpdatePartitionSpec; // implementer-specific check

Try / catch

try {
  update.addNonDefaultSpec().addField("day");
} catch (UnsupportedOperationException e) {
  // fall back to default-spec update
  update.addField("day");
}

Prevention

Only call addNonDefaultSpec() on implementations documented to support it.
Prefer default-spec evolution unless you specifically need a non-default spec.
Read the class name in the error to identify the lacking implementation.

When it happens

Trigger: Calling updatePartitionSpec(...).addNonDefaultSpec() on an implementation that has not overridden the default, e.g. certain catalog- or transaction-backed UpdatePartitionSpec instances.

Common situations: Trying to evolve a table with a non-default (legacy) partition spec via an update object obtained from a context that only supports default-spec updates; writing generic table-evolution code that assumes all implementations support the method.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/fa40f37ba2e57cd8. Report an issue: GitHub.