ShrinkWrap
  1. ShrinkWrap
  2. SHRINKWRAP-461

SeekableInMemoryByteChannel returns incorrect value for EOF

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 1.1.2
    • Fix Version/s: 1.1.3
    • Component/s: api
    • Labels:
      None
    • Environment:
      Window 7, Java 7
    • Similar Issues:
      Show 10 results 

      Description

      The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data.

      The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteChannel.html#read(java.nio.ByteBuffer) ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl.

      Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read.

      I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes().

      A unit test showing the issue:

          @Test
          public void test() throws IOException {
              JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class);
              FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive);
              Path path = vfs.getPath("out.json");
              try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) {
                  new GsonBuilder().create().toJson("Test", writer);
              }
              try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { 
                  assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class));
              }
          }
      

        Activity

        Hide
        Resurgam Immortius
        added a comment -

        The problem can more easily be reproduced by using Files.readAllLines(), which will similarly fail.

        Show
        Resurgam Immortius
        added a comment - The problem can more easily be reproduced by using Files.readAllLines(), which will similarly fail.
        Hide
        Andrew Rubinger
        added a comment -

        Upstream: Thank you very much for this PR; great work. The comma in the API JavaDocs for SeekableByteChannel confused me in implementing this; at first glance it looked like either 0 or -1 was an appropriate return value. Good catch.

        63eb258e9a058e36f7c542d0ee2bd1bbe9a6b011

        Show
        Andrew Rubinger
        added a comment - Upstream: Thank you very much for this PR; great work. The comma in the API JavaDocs for SeekableByteChannel confused me in implementing this; at first glance it looked like either 0 or -1 was an appropriate return value. Good catch. 63eb258e9a058e36f7c542d0ee2bd1bbe9a6b011

          People

          • Assignee:
            Andrew Rubinger
            Reporter:
            Resurgam Immortius
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: