apache/beam · warning · UnsupportedOperationException

Caller does not own the underlying input stream and should…

Error message

Caller does not own the underlying input stream  and should not call mark().

What it means

UnownedInputStream.mark() also throws UnsupportedOperationException because the wrapper cannot safely delegate mark/reset for a stream it does not own (mark/reset state would leak to the real owner). markSupported() returns false. Callers must not attempt to mark positions on this stream.

Solutions

  1. Do not call mark() on UnownedInputStream; buffer the data yourself (e.g. read into a byte[]/ByteArrayInputStream) if lookahead is needed.
  2. Guard any mark usage with markSupported(), which returns false for this wrapper.
  3. If mark/reset is required, copy the underlying owned stream into a BufferedInputStream or ByteArrayInputStream that you own and wrap that.
  4. Use PushbackInputStream around the owned stream at the ownership boundary instead of marking the wrapper.

Example fix

// before
in.mark(1024); // throws UnsupportedOperationException
int c = in.read();
in.reset();
// after
if (in.markSupported()) {
  in.mark(1024);
}
InputStream buffered = new BufferedInputStream(new UnownedInputStream(owned)); // or buffer bytes yourself
buffered.mark(1024);
Defensive patterns

Strategy: type-guard

Type guard

boolean supportsMarking(InputStream in) {
  return in.markSupported();
}

Try / catch

try {
  in.mark(limit);
} catch (UnsupportedOperationException e) {
  // fall back to buffering bytes manually
}

Prevention

When it happens

Trigger: Calling mark(readlimit) on an UnownedInputStream, or using helper code that calls mark() unconditionally (some parsers/buffer utilities call mark first if not guarded by markSupported()).

Common situations: Handing an UnownedInputStream to libraries that use mark/reset (e.g. some JSON/XML parsers, PushbackInputStream patterns) without checking markSupported(), causing runtime failure during parsing.

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/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/a2622d541696e1fe. Report an issue: GitHub.

Appendix: source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/util/UnownedInputStream.java:61

  public void close() throws IOException {
    throw new UnsupportedOperationException(
        "Caller does not own the underlying input stream " + " and should not call close().");
  }

  @Override
  public boolean equals(@Nullable Object obj) {
    return obj instanceof UnownedInputStream && ((UnownedInputStream) obj).in.equals(in);
  }

  @Override
  public int hashCode() {
    return in.hashCode();
  }

  @SuppressWarnings("UnsynchronizedOverridesSynchronized")
  @Override
  public void mark(int readlimit) {
    throw new UnsupportedOperationException(
        "Caller does not own the underlying input stream " + " and should not call mark().");
  }

  @Override
  public boolean markSupported() {
    return false;
  }

  @SuppressWarnings("UnsynchronizedOverridesSynchronized")
  @Override
  public void reset() throws IOException {
    throw new UnsupportedOperationException(
        "Caller does not own the underlying input stream " + " and should not call reset().");
  }

  @Override
  public String toString() {
    return MoreObjects.toStringHelper(UnownedInputStream.class).add("in", in).toString();

View on GitHub (pinned to 12126d8942)