hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Broberg (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HADOOP-8003) Make SplitCompressionInputStream an interface instead of an abstract class
Date Fri, 24 Feb 2012 00:43:48 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-8003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Tim Broberg resolved HADOOP-8003.

    Resolution: Won't Fix

This is not fixable.

SplitCompressionInputStream is constrained to be an InputStream - Callers read() from it.
...and it's right there in the name.

InputStream does not contain any interfaces with the necessary buttons present that SplitCompressionInputStream
can extend, so the available options are:
 1 - to extend InputStream or some descendent. This is the current design.
 2 - Define an interface containing all the methods of CompressedInputStream, requiring implementing
classes to pass them all through. This requires equivalent work to the current design.
 3 - Modify InputStream in the java library to make use of interfaces. Madness.

The original design was the correct one given the definition of InputStream in the standard
Java library.
> Make SplitCompressionInputStream an interface instead of an abstract class
> --------------------------------------------------------------------------
>                 Key: HADOOP-8003
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8003
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: io
>    Affects Versions: 0.21.0, 0.22.0, 0.23.0, 1.0.0
>            Reporter: Tim Broberg
> To be splittable, a codec must extend SplittableCompressionCodec which has a function
returning a SplitCompressionInputStream.
> SplitCompressionInputStream is an abstract class which extends CompressionInputStream,
the lowest level compression stream class.
> So, no codec that wants to be splittable can reuse any code from DecompressorStream or
> You either have to duplicate that code, or not be splittable.
> SplitCompressionInputStream adds just a few very thin functions. Can we make this an
interface rather than an abstract class to allow splittable decompression streams to extend
DecompressorStream, BlockDecompressorStream, or whatever else we should scheme up in the future?
> To my knowledge, this would impact only the BZip2 codec. None of the other implement
this form of splittability yet.
> LineRecordReader looks only at whether the codec is an instance of SplittableCompressionCodec,
and then calls the appropriate version of createInputStream. This would not change, so the
application code should not have to change, just BZip and SplitCompressionInputStream.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message