Add HttpUrlConnection backed implementation of CronetEngine.

components/cronet/android/api/src/org/chromium/net/InputStreamChannel.java

Index: components/cronet/android/api/src/org/chromium/net/InputStreamChannel.java
diff --git a/components/cronet/android/api/src/org/chromium/net/InputStreamChannel.java b/components/cronet/android/api/src/org/chromium/net/InputStreamChannel.java
new file mode 100644
index 0000000000000000000000000000000000000000..1637bd8f2546843106095d21d4ac46b7c6674f2d
--- /dev/null
+++ b/components/cronet/android/api/src/org/chromium/net/InputStreamChannel.java
@@ -0,0 +1,77 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.net;
+
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.ByteBuffer;
+import java.nio.channels.ReadableByteChannel;
+import java.util.concurrent.atomic.AtomicBoolean;
+
+/**
+ *  Adapts an {@link InputStream} into a {@link ReadableByteChannel}, exactly like

[pauljensen, 2015/12/08 19:49:52]

extra space before "Adapts"

[Charles, 2015/12/11 16:45:39]

Done.

+ * {@link java.nio.channels.Channels#newChannel(InputStream)} does, but more efficiently, since it
+ * does not allocate a temporary buffer if it doesn't have to, and it freely takes advantage of
+ * {@link FileInputStream}'s trivial conversion to {@link java.nio.channels.FileChannel}.
+ */
+final class InputStreamChannel implements ReadableByteChannel {
+    private static final int MAX_TMP_BUFFER_SIZE = 16384;
+    private static final int MIN_TMP_BUFFER_SIZE = 4096;
+    private final InputStream mInputStream;
+    private final AtomicBoolean mIsOpen = new AtomicBoolean(true);
+
+    private InputStreamChannel(InputStream inputStream) {
+        this.mInputStream = inputStream;
+    }
+
+    static ReadableByteChannel wrap(InputStream inputStream) {
+        if (inputStream instanceof FileInputStream) {
+            return ((FileInputStream) inputStream).getChannel();
+        }
+        return new InputStreamChannel(inputStream);
+    }
+
+    @Override
+    public int read(ByteBuffer dst) throws IOException {
+        final int read;
+        if (dst.hasArray()) {
+            read = mInputStream.read(
+                    dst.array(), dst.arrayOffset() + dst.position(), dst.remaining());
+            if (read > 0) {
+                dst.position(dst.position() + read);
+            }
+        } else {
+            // Since we're allocating a buffer for every read, we want to choose a good size - on
+            // Android, the only case where

[pauljensen, 2015/12/08 19:49:52]

it looks like you used "git cl format" to line-wrap your comments.  could you
rewrap them in a more sane way?

[Charles, 2015/12/11 16:45:39]

Done.

+            // a ByteBuffer won't have a backing byte[] is if it was created wrapping a void * in
+            // native code, or if it
+            // represents a memory-mapped file. Especially in the latter case, we want to avoid
+            // allocating a buffer that
+            // could be very large.
+            final int possibleToRead = Math.min(
+                    Math.max(mInputStream.available(), MIN_TMP_BUFFER_SIZE), dst.remaining());
+            final int reasonableToRead = Math.min(MAX_TMP_BUFFER_SIZE, possibleToRead);
+            byte[] tmpBuf = new byte[Math.min(reasonableToRead, MAX_TMP_BUFFER_SIZE)];

[pauljensen, 2015/12/08 19:49:52]

it's interesting that you marked your ints final but not your byte[].  I get
int's are primitive and an array is a reference.  Is there a style guide
recommendation for this?  otherwise it seems inconsistent.

[Charles, 2015/12/11 16:45:39]

The style guide is "don't put final on local variables, unless it's required or
it makes the code easier to follow". I tend to interpret that in a way that uses
final on variables in three cases:

1. Variable is accessed in an anonymous class (has to be final)
2. Variable is declared, and there's some complex code that initializes it - by
declaring it final, the compiler proves that it can only be initialized once,
and that it must be initialized. The "final int read" up earlier lets you skip
checking that its results might not be populated or might be overwritten.
3. Variable is in a mix of other, similarly typed variables. I could see myself
accidentally reassigning possibleToRead or reasonableToRead, since there are a
bunch of ints floating around those three lines of code, but that case is a
little less defensible. 

I didn't mark tmpBuf final, because it's the only byte[] in that area of code,
and the code from when it's declared to when it goes out of scope is very
simple, and there's little opportunity for confusion.

[pauljensen, 2016/03/17 12:10:04]

Charles, what is "The style guide" you are referring to?

+            read = mInputStream.read(tmpBuf);
+            if (read > 0) {
+                dst.put(tmpBuf, 0, read);
+            }
+        }
+        return read;
+    }
+
+    @Override
+    public boolean isOpen() {
+        return mIsOpen.get();
+    }
+
+    @Override
+    public void close() throws IOException {
+        if (mIsOpen.compareAndSet(true, false)) {
+            mInputStream.close();
+        }
+    }
+}