apache/druid · error · UOE
HDFS CharSequence not supported
Error message
HDFS CharSequence not supported
What it means
Same pattern as openReader: the HDFS FileObject's getCharContent(ignoreEncodingErrors) throws UOE("HDFS CharSequence not supported") because returning the whole file content as a CharSequence is not implemented for HDFS-backed binary segment files. The method exists only to satisfy the javax.tools.FileObject interface and is intentionally unimplemented for this storage backend.
Source
Thrown at extensions-core/hdfs-storage/src/main/java/org/apache/druid/storage/hdfs/HdfsDataSegmentPuller.java:146
}
@Override
public OutputStream openOutputStream() throws IOException
{
final FileSystem fs = path.getFileSystem(config);
return fs.create(path, overwrite);
}
@Override
public Reader openReader(boolean ignoreEncodingErrors)
{
throw new UOE("HDFS Reader not supported");
}
@Override
public CharSequence getCharContent(boolean ignoreEncodingErrors)
{
throw new UOE("HDFS CharSequence not supported");
}
@Override
public Writer openWriter()
{
throw new UOE("HDFS Writer not supported");
}
@Override
public long getLastModified()
{
try {
final FileSystem fs = path.getFileSystem(config);
return fs.getFileStatus(path).getModificationTime();
}
catch (IOException ex) {
throw new HdfsIOException(ex);
}View on GitHub (pinned to 9b90983fd2)
Solutions
- Read via openInputStream() and materialize the CharSequence yourself from the bytes.
- Use a different URIDataPuller/FileObject implementation for character-content access.
- Guard call sites: for hdfs:// scheme URIs, never call getCharContent.
Example fix
// before
CharSequence cs = fileObject.getCharContent(false);
// after
try (InputStream in = fileObject.openInputStream()) {
CharSequence cs = new String(ByteStreams.toByteArray(in), StandardCharsets.UTF_8);
} Defensive patterns
Strategy: type-guard
Validate before calling
if ("hdfs".equalsIgnoreCase(uri.getScheme())) { /* do not call getCharContent */ } Type guard
boolean supportsCharContent(FileObject fo) { return !isHdfsFileObject(fo); } Try / catch
try { return fo.getCharContent(false); }
catch (UOE e) { return slurpInputStream(fo.openInputStream()); } Prevention
- Prefer openInputStream + explicit decoding for all HDFS text access.
- Centralize FileObject usage so unsupported methods are never reachable from production code paths.
When it happens
Trigger: Calling getCharContent on the FileObject produced by HdfsDataSegmentPuller.buildFileObject — any consumer expecting in-memory character content of an hdfs:// URI.
Common situations: Generic FileObject-based tooling that buffers file content as CharSequence; code ported from local-filesystem FileObjects to HDFS URIs without changing the content-access API.
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
- HDFS Reader not supported
- HDFS Writer not supported
- CharSequence not supported
- Casting to float type is not supported
- Casting to long type is not supported
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/e35e62a52cd7a0d1.
Report an issue: GitHub.