overloading BlockCompressedInputStream.checkTerminator to support NIO #890

Merged
merged 2 commits into from Jun 8, 2017

Conversation

Projects
None yet
4 participants
Contributor

lbergelson commented Jun 6, 2017

BlockCompressedInputStream.checkTerminator only worked on files. Gatk4 needs it to accept Paths and ideally SeekableByteChannels directly. Adding overloads that take Path and SeekableByteChannel and refactoring the internals to use SeekableByteChannel instead of RandomAccessFile.

Checklist

  • Code compiles correctly
  • New tests covering changes and new functionality
  • All tests passing
  • Is not backward compatible (breaks binary or source compatibility)
@lbergelson lbergelson overloading BlockCompressedInputStream.checkTerminator to support NIO
adding overloads that take Path and SeekableByteChannel
e14ebe5

droazen was assigned by lbergelson Jun 6, 2017

lbergelson requested a review from droazen Jun 6, 2017

codecov-io commented Jun 6, 2017 edited

Codecov Report

Merging #890 into master will increase coverage by 0.017%.
The diff coverage is 75%.

@@               Coverage Diff               @@
##              master      #890       +/-   ##
===============================================
+ Coverage     65.045%   65.062%   +0.017%     
- Complexity      7239      7251       +12     
===============================================
  Files            528       528               
  Lines          31892     31942       +50     
  Branches        5444      5460       +16     
===============================================
+ Hits           20744     20782       +38     
- Misses          9008      9016        +8     
- Partials        2140      2144        +4
Impacted Files Coverage Δ Complexity Δ
...sjdk/samtools/util/BlockCompressedInputStream.java 73.881% <75%> (-1.021%) 77 <8> (+4)
...a/htsjdk/samtools/cram/encoding/rans/Decoding.java 82.143% <0%> (-3.571%) 11% <0%> (-1%)
...dk/samtools/seekablestream/SeekableHTTPStream.java 54.545% <0%> (-1.515%) 9% <0%> (-1%)
src/main/java/htsjdk/samtools/util/Interval.java 63.462% <0%> (+1.923%) 23% <0%> (+1%) ⬆️
...c/main/java/htsjdk/samtools/util/IntervalList.java 67.391% <0%> (+2.479%) 67% <0%> (+9%) ⬆️
@droazen

Review complete, back to @lbergelson for changes.

+ return checkTermination(file == null ? null : file.toPath());
+ }
+
+ public static FileTermination checkTermination(final Path path) throws IOException {
@droazen

droazen Jun 7, 2017

Contributor

Expand existing unit tests to call into these two new overloads as well.

@lbergelson

lbergelson Jun 7, 2017

Contributor

done

+ }
+ }
+
+ public static FileTermination checkTermination(SeekableByteChannel channel) throws IOException {
@droazen

droazen Jun 7, 2017

Contributor

Add javadoc for the new overloads, including stream closing behavior.

@lbergelson

lbergelson Jun 7, 2017

Contributor

done

+ return FileTermination.HAS_TERMINATOR_BLOCK;
+ }
+ final int bufsize = (int)Math.min(fileSize, BlockCompressedStreamConstants.MAX_COMPRESSED_BLOCK_SIZE);
+ final byte[] buf = new byte[bufsize];
@droazen

droazen Jun 7, 2017

Contributor

While you're at it, you might want to rename buf as well to distinguish from the member variable

@lbergelson

lbergelson Jun 7, 2017

Contributor

renamed

- } else {
- return FileTermination.DEFECTIVE;
- }
+ final ByteBuffer byteBuffer = ByteBuffer.wrap(buf, i + BlockCompressedStreamConstants.GZIP_BLOCK_PREAMBLE.length, 4);
@droazen

droazen Jun 7, 2017

Contributor

You might want to change the naming here to distinguish from bytebuffer above

@lbergelson

lbergelson Jun 7, 2017

Contributor

bytebuffer lowercase renamed

+ return FileTermination.DEFECTIVE;
+ }
+
+ private static void readFully(SeekableByteChannel channel, ByteBuffer dst) throws IOException {
@droazen

droazen Jun 7, 2017

Contributor

Add unit test for readFully()

@lbergelson

lbergelson Jun 7, 2017

Contributor

done

@droazen droazen assigned lbergelson and unassigned droazen Jun 7, 2017

@lbergelson lbergelson responding to david's comments
1734eb9

@lbergelson lbergelson merged commit 98c2438 into master Jun 8, 2017

4 of 5 checks passed

codecov/changes 3 files have unexpected coverage changes not visible in diff.
Details
codecov/patch 75% of diff hit (target 65.045%)
Details
codecov/project 65.062% (+0.017%) compared to 630aa48
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

lbergelson deleted the lb_block_compressed_input_stream_path branch Jun 8, 2017

public static FileTermination checkTermination(final File file) throws IOException {
- final long fileSize = file.length();
+ return checkTermination(file == null ? null : file.toPath());
@pshapiro4broad

pshapiro4broad Jun 8, 2017

Won't this cause checkTermination(Path) to throw when file == null? If so avoiding the NPE here doesn't seem worthwhile. Maybe you want to return FileTermination.DEFECTIVE in that case?

@lbergelson

lbergelson Jun 8, 2017

Contributor

@pshapiro4broad It absolutely just shifts the npr to later. I wanted to just keep the exact behavior of the original function, which was to NPR somewhere later. It does probably makes sense to check for null and throw a nice exception instead of an NPR. Returning defective would be a bad idea for a null file I think since it would hide other errors.

- raFile.close();
+ //if an exception was thrown we don't want to reset the position because that would be likely to throw again
+ //and suppress the initial exception
+ if(!exceptionThrown) {
@pshapiro4broad

pshapiro4broad Jun 8, 2017

This code is not consistent with its use of spaces around if elements. Here there's no space between if and (. On line 679 there is a space there, but not after the ). On line 654 there are spaces both before and after.

The code should be consistent; putting a space before and after the ()s is the java standard and is what most of the existing code does, so I would recommend formatting it that way.

The try on line 606 is also formatted inconsistently with respect to the surrounding code.

@lbergelson

lbergelson Jun 8, 2017

Contributor

That's a good point. I'm not sure it's worth opening another pr over though since I've already merged this one.

@pshapiro4broad

pshapiro4broad Jun 8, 2017

no worries, something to keep in mind for next time :)

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