Is protocol buffers optimized to use java nio for file IO?

Question

I am working with protocol buffers and am wondering if the:

mergeDelimitedFrom(FileInputStream fis)

method is optimized to use java nio? I don't really feel like going to the src to find out... but maybe I will. I feel like it should or have the option to use both. I am guessing that it isn't. If it doesn't - I guess you would have to parse the bytes yourself and handle the delimiter manually if you want nio?

Not super confident with the nio api right now but don't you just call:

 getChannel()

on the FileInputStream to use nio, so hypothetically nio could be used because a FileInputStream is provided to the mergeDelimitedFrom method?

Related post but more directed towards network IO:

Using Google Protocol Buffers with Java NIO?

Answer 1

I was thinking this code wasn't part of the generated code but I guess it is...

MergeDelimitedFrom calls CodedInputStream.readRawVarint32 below:

public static int readRawVarint32(
  final int firstByte, final InputStream input) throws IOException {
if ((firstByte & 0x80) == 0) {
  return firstByte;
}

int result = firstByte & 0x7f;
int offset = 7;
for (; offset < 32; offset += 7) {
  final int b = input.read();
  if (b == -1) {
    throw InvalidProtocolBufferException.truncatedMessage();
  }
  result |= (b & 0x7f) << offset;
  if ((b & 0x80) == 0) {
    return result;
  }
}
// Keep reading up to 64 bits.
for (; offset < 64; offset += 7) {
  final int b = input.read();
  if (b == -1) {
    throw InvalidProtocolBufferException.truncatedMessage();
  }
  if ((b & 0x80) == 0) {
    return result;
  }
}
throw InvalidProtocolBufferException.malformedVarint();

}

Looks like plain old java.io.