10-06 12:03:39.450 1327 2243 W System.err: java.lang.NullPointerException: Attempt to read from field 'int com.android.okio.Segment.limit' on a null object reference
10-06 12:03:39.460 1327 2261 E AndroidRuntime: FATAL EXCEPTION: Thread-324
10-06 12:03:39.460 1327 2261 E AndroidRuntime: java.lang.NullPointerException: Attempt to read from field 'int com.android.okio.Segment.limit' on a null object reference
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okio.OkBuffer.write(OkBuffer.java:574)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okio.OkBuffer.read(OkBuffer.java:610)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okio.RealBufferedSource.read(RealBufferedSource.java:56)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.http.HttpConnection$FixedLengthSource.read(HttpConnection.java:465)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.Util.skipAll(Util.java:227)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.http.HttpConnection.discard(HttpConnection.java:235)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.http.HttpConnection$FixedLengthSource.close(HttpConnection.java:487)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.Util.closeQuietly(Util.java:97)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.http.HttpEngine.close(HttpEngine.java:574)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.android.okhttp.internal.http.HttpURLConnectionImpl.disconnect(HttpURLConnectionImpl.java:113)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.touchtype_fluency.util.HttpDownload.b(Unknown Source)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.touchtype_fluency.util.HttpDownload.interrupt(Unknown Source)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at com.touchtype_fluency.util.Downloader$2.run(Unknown Source)
10-06 12:03:39.460 1327 2261 E AndroidRuntime: at java.lang.Thread.run(Thread.java:818)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okio.OkBuffer.write(OkBuffer.java:574)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okio.OkBuffer.read(OkBuffer.java:610)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okio.RealBufferedSource.read(RealBufferedSource.java:56)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okhttp.internal.http.HttpConnection$FixedLengthSource.read(HttpConnection.java:465)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okhttp.internal.Util.skipAll(Util.java:227)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okhttp.internal.http.HttpConnection.discard(HttpConnection.java:235)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okhttp.internal.http.HttpConnection$FixedLengthSource.close(HttpConnection.java:487)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okio.RealBufferedSource.close(RealBufferedSource.java:204)
10-06 12:03:39.460 1327 2243 W System.err: at com.android.okio.RealBufferedSource$1.close(RealBufferedSource.java:187)
10-06 12:03:39.460 1327 2243 W System.err: at java.io.BufferedInputStream.close(BufferedInputStream.java:141)
10-06 12:03:39.460 1327 2243 W System.err: at org.apache.commons.io.input.ProxyInputStream.close(ProxyInputStream.java:102)
10-06 12:03:39.460 1327 2243 W System.err: at java.io.FilterInputStream.close(FilterInputStream.java:64)
10-06 12:03:39.460 1327 2243 W System.err: at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:178)
10-06 12:03:39.460 1327 2243 W System.err: at com.touchtype_fluency.util.HttpDownload.downloadZip(Unknown Source)
10-06 12:03:39.460 1327 2243 W System.err: at com.touchtype_fluency.util.b$1.onDownload(Unknown Source)
10-06 12:03:39.460 1327 2243 W System.err: at com.touchtype_fluency.util.Downloader$1.run(Unknown Source)
10-06 12:03:39.460 1327 2243 W System.err: at java.lang.Thread.run(Thread.java:818)

I'm tempted to build a ByteString that uses a linked list of segments behind-the-scenes. You'd get it by calling Buffer.readByteString(), but no copy would happen if certain size thresholds were met: the segments would just be reassigned to the ByteString.

We could go even further in efficiency & complexity by supporting Buffers composed of a mix of readonly and immutable segments.

I’ve run into a tricky situation with OkHttp and Okio. I’m trying to write a RequestBody decorator for OkHttp that counts the bytes written.

See this Gist since it’s a bit difficult to explain.

The body gets a BufferedSink for writing that I decorate as well (using ForwardingSink) to do the actual counting. This works fine until I need to pass a BufferedSink forward by re-buffering the decorated sink. This breaks the uploading process since there are now two buffers layered on each other.

It would be great if I could separate the original sink from the BufferedSink like I can do with the buffer. Then I could decorate that instead like this:

@Override
public void writeTo(BufferedSink bufferedSink) throws IOException {
    Sink sink = bufferedSink.sink();

    countingSink = new CountingSink(sink);

    delegate.writeTo(Okio.buffer(countingSink));
}

It seems that the only way I can currently do this is by implementing BufferedSink. I could also implement the RequestBody instead of decorating it, but the downside would be that I’d have to do that for all of the request body types.

We don't support anything like SeekableByteChannel. Would potentially be useful for random access. Could be very useful to navigate ZIP files, dex files, etc.

Colin recommended a Store interface that permitted read and write access to a random access file.

Do I need manually call close() like this?

    // Read inputStream and output to temFile path
    Source source = Okio.source(inputStream); 
    BufferedSource buffer = Okio.buffer(source);
    Sink sink = Okio.sink(tmpFile);
    buffer.readAll(sink); 

    sink.close();
    buffer.close();
    source.close();

We switched to Volley + OkHttp recently and it's been working out great so far. However, we've noticed some crashes happening internally to Okio in our bug reporting tool and I just thought I'll put it up here.

We are using OkHttp 2.0.0, okhttp-url-connection 2.0.0 and okio 1.0.1.

java.lang.AssertionError: libcore.io.ErrnoException: getsockname failed: EBADF (Bad file number)
       at libcore.io.IoBridge.getSocketLocalAddress(IoBridge.java:665)
       at libcore.io.IoBridge.recvfrom(IoBridge.java:564)
       at java.net.PlainSocketImpl.read(PlainSocketImpl.java:488)
       at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
       at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
       at okio.Okio$2.read(SourceFile:136)
       at okio.AsyncTimeout$2.read(SourceFile:211)
       at okio.RealBufferedSource.indexOf(SourceFile:244)
       at okio.RealBufferedSource.readUtf8LineStrict(SourceFile:191)
       at com.squareup.okhttp.internal.http.HttpConnection.readResponse(SourceFile:189)
       at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(SourceFile:101)
       at com.squareup.okhttp.internal.http.HttpEngine.readResponse(SourceFile:676)
       at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(SourceFile:426)
       at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(SourceFile:371)
       at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(SourceFile:466)
       at com.android.volley.toolbox.HurlStack.performRequest(SourceFile:109)
       at com.android.volley.toolbox.BasicNetwork.performRequest(SourceFile:93)
       at com.android.volley.NetworkDispatcher.run(SourceFile:110)
Caused by: libcore.io.ErrnoException: getsockname failed: EBADF (Bad file number)
       at libcore.io.Posix.getsockname(Posix.java)
       at libcore.io.ForwardingOs.getsockname(ForwardingOs.java:65)
       at libcore.io.IoBridge.getSocketLocalAddress(IoBridge.java:660)
       at libcore.io.IoBridge.recvfrom(IoBridge.java:564)
       at java.net.PlainSocketImpl.read(PlainSocketImpl.java:488)
       at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
       at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
       at okio.Okio$2.read(SourceFile:136)
       at okio.AsyncTimeout$2.read(SourceFile:211)
       at okio.RealBufferedSource.indexOf(SourceFile:244)
       at okio.RealBufferedSource.readUtf8LineStrict(SourceFile:191)
       at com.squareup.okhttp.internal.http.HttpConnection.readResponse(SourceFile:189)
       at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(SourceFile:101)
       at com.squareup.okhttp.internal.http.HttpEngine.readResponse(SourceFile:676)
       at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(SourceFile:426)
       at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(SourceFile:371)
       at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(SourceFile:466)
       at com.android.volley.toolbox.HurlStack.performRequest(SourceFile:109)
       at com.android.volley.toolbox.BasicNetwork.performRequest(SourceFile:93)
       at com.android.volley.NetworkDispatcher.run(SourceFile:110)

int and long with radix. Any others? Naming convention?

BufferedSource source = Okio.buffer(Okio.source(inputStream));
String result = source.readUtf8();
source.close();

Does okio BufferedSource close InputStream when I call its close method?

PS: haven't found tag on stackoverflow for okio

I'm downloading using okhttp with okio.
code:

            InputStream stream = response.body().byteStream();
            BufferedSource source = Okio.buffer(Okio.source(stream));
            BufferedSink sink = Okio.buffer(Okio.sink(new File(path)));
            long readBytes, downloaded = 0l;
            int bufferSize = 8 * 1024;
            while ((readBytes = source.read(sink.buffer(), bufferSize)) > 0) {
                downloaded += readBytes;
                if (downloaded > 0) {
                    // publishProgress
                }
            }
            sink.flush();
            sink.close();
            source.close();

and memeory usage:

and I write like this, the issue's gone

            InputStream stream = response.body().byteStream();
            FileOutputStream fileOutputStream = new FileOutputStream(new File(path));
            byte[] buffer = new byte[8 * 1024];
            int count;
            long downloaded = 0;
            while ((count = stream.read(buffer)) > 0) {
                fileOutputStream.write(buffer, 0, count);
                downloaded += count;
                if (downloaded > 0) {
                   // publishProgress
                }
            }
            fileOutputStream.flush();
            fileOutputStream.close();
            stream.close();

is there any problem of my code or is that a bug happened to me? thanks

• Write directly to an OutputStream
• Read directly from an InputStream.

Buffer.writeUtf8 states:

// TODO: inline UTF-8 encoding to save allocating a byte[]?

@swankjesse did a bit of testing here and found it slightly faster for short strings.

Let's do more comprehensive tests and determine if there's both a clear tipping point between the two implementations and justification that the extra code is actually worth its weight in speedups.

@swankjesse any idea what happened here?

Using Okio 1.2.0 along with OkHttp 2.1.0, I'm seeing an NPE when reading HTTP responses:

java.lang.NullPointerException
    at okio.Buffer.write(Buffer.java:854)
    at okio.RealBufferedSink.write(RealBufferedSink.java:44)
    at com.squareup.okhttp.internal.http.HttpConnection$FixedLengthSink.write(HttpConnection.java:300)
    at okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:140)
    at okio.RealBufferedSink.write(RealBufferedSink.java:69)
    at com.squareup.okhttp.RequestBody$1.writeTo(RequestBody.java:72)
    at com.squareup.okhttp.Call.getResponse(Call.java:237)  
    at com.squareup.okhttp.Call.execute(Call.java:84)

Evidently, source.head is null. Could this be due to the older OkHttp version?

Benchmarks are great, in that they measure the inherent performance of something, but more useful is comparison to the same "something" implemented in what okio is meant to replace.

For example, how does okio compare to Apache commons-io's IOUtils for reading a file, or parsing an XML or JSON file, or some other common I/O code pattern?

For example, see the HikariCP Connection Pool benchmarks or the Boon JSON Parser benchmarks.

In a project that I've converted to use Okio for quite a few disk as well as network operations, I'm finding that disk operations get interrupted where previously (using input/outputstreams directly) they didn't. I believe 404fe3a from #15 introduced this behaviour.

The problem is that Okio.source(final InputStream in) and Okio.sink(final OutputStream out) use the default Timeout() constructor and that its throwIfReachedMethod is defined as follows:

  public void throwIfReached() throws IOException {
    if (Thread.interrupted()) {
      throw new InterruptedIOException();
    }

    if (hasDeadline && System.nanoTime() > deadlineNanoTime) {
      throw new IOException("deadline reached");
    }
  }

So where I'm using sources and sinks for disk operations on threads that I interrupt, I get InterruptedIOException. What I actually want is for the operations to complete - I detect the interrupt later.

I note that Timeout.NONE is defined, as are Okio.source(final InputStream in, final Timeout timeout) and sink(final OutputStream out, final Timeout timeout), so one way for me to solve this would be to pass Timeout.NONE. What's stopping me from doing this though is the fact that these two methods are private. So for now I think I'll just have to restart interrupted disk operations and reinterrupt the thread when they've completed.

I speculate there are two ways to solve this:

1. Make the above possible by making Okio.source(final InputStream in, final Timeout timeout) and sink(final OutputStream out, final Timeout timeout) public.
   and/or
2. Change Okio.source(final InputStream in) and Okio.sink(final OutputStream out) to use Timeout.NONE - to me this would be the more sensible default in that finding the wrapped input/outputstreams intercepted thread interrupts is not what I'd expected - I expected the resulting sources/sinks to otherwise behave just like the streams they wrap.

If you can advise which if any of the above is/are preferable I'll be happy to implement and create a pull request.

Hi guys,
WIth Android Studio: 1.2.RC

I enabled proguard in .gradle:

          minifyEnabled=true

and added these rules to my proguard-rules.pro:

-dontwarn com.squareup.**
-dontwarn okio.**

and added these lint rules to my .gradle file:

        warningsAsErrors false
        abortOnError false
        disable 'InvalidPackage'

But I still get these warning when I try to run the app in debug mode:

Warning: okio.DeflaterSink: can't find referenced class org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement
Warning: okio.Okio: can't find referenced class java.nio.file.Files
Warning: okio.Okio: can't find referenced class java.nio.file.Files
Warning: okio.Okio: can't find referenced class java.nio.file.Files
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement
Warning: there were 14 unresolved references to classes or interfaces.
         You may need to add missing library jars or update their versions.
         If your code works fine without the missing classes, you can suppress
         the warnings with '-dontwarn' options.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
:app:proguardDebug FAILED

It's so weird since I also added these rules/options to all my library modules that depend on OkHttp/Picasso, I don't know where went wrong, perhaps this is a Android Studio bug ? Does anyone have any clues to this problem ?

Conceding this is an uncommon use case, http2 has a 24bit unsigned length field. It feel cleaner if okhttp could ask okio to read/writeMedium.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-4.1

I noticed I can crash an Android app using Okio when I pause the corresponding server interface for debugging purposes. This might be something you want to look into.

java.net.SocketTimeoutException
D      at java.net.PlainSocketImpl.read(PlainSocketImpl.java:488)
D      at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:37)
D      at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:237)
D      at okio.Okio$2.read(Okio.java:137)
D      at okio.AsyncTimeout$2.read(AsyncTimeout.java:211)
D      at okio.RealBufferedSource.indexOf(RealBufferedSource.java:295)
D      at okio.RealBufferedSource.indexOf(RealBufferedSource.java:289)
D      at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:196)
D      at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:190)
D      at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
D      at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:830)
D      at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:95)
D      at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:823)
D      at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:684)
D      at com.squareup.okhttp.Call.getResponse(Call.java:272)
D      at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:228)
D      at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:199)
D      at com.squareup.okhttp.Call.execute(Call.java:79)
D      at retrofit.client.OkClient.execute(OkClient.java:53)
D      at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:326)
D      at retrofit.RestAdapter$RestHandler.access$100(RestAdapter.java:220)
D      at retrofit.RestAdapter$RestHandler$1.invoke(RestAdapter.java:265)
D      at retrofit.RxSupport$2.run(RxSupport.java:55)
D      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
D      at java.util.concurrent.FutureTask.run(FutureTask.java:237)
D      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
D      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
D      at retrofit.Platform$Android$2$1.run(Platform.java:142)
D      at java.lang.Thread.run(Thread.java:818)

The Android app uses com.squareup.okhttp:okhttp-urlconnection:2.3.0.

There should be a mark / reset on the Buffer and/or Source objects. For example, I read a few bytes from a socket and then analyze those bytes to determine how many further bytes to ready. I want the consumer of my Buffer to receive all of the read bytes but the Buffer's internal offset has been moved as a result of my examining the initial bytes.

Observed in okio 1.0.1; haven't upgraded to 1.2.0 yet. I didn't see any open or closed issues like this, but if this is already fixed then sorry to have missed it. Regrettably I can't reliably reproduce this, but at least here is a stacktrace:

java.lang.ArrayIndexOutOfBoundsException: length=2048; index=2048
        at okio.Buffer.readByte(Buffer.java:237)
        at okio.Buffer.readShort(Buffer.java:269)
        at okio.Buffer.readShortLe(Buffer.java:356)
        at okio.RealBufferedSource.readShortLe(RealBufferedSource.java:203)

I see this regularly in our analytics, and today for the first time it happened to me. It's entirely possible that I'm doing something incorrectly. The crash appears to be a bookkeeping error - in readByte(), where size is non-zero but head.pos is equal to head.data.length.

If this is fixed already, great. If I can offer more info, please let me know. Thanks!

Hello.

I have this problem that I've been trying to fix for days. Okio tries to log a body on a 204 http response and it ends up in a EOFException.
I'm out of ideas. Any help would be really appreciated.

<--- HTTP 204 https://some.url/
Server: nginx
Date: Tue, 10 Mar 2015 12:38:53 GMT
Content-Type: text/html
Connection: keep-alive
Cache-Control: private, must-revalidate
pragma: no-cache
expires: -1
Set-Cookie: flash_bag=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; httponly
X-Varnish: 391643738
OkHttp-Selected-Protocol: http/1.1
OkHttp-Sent-Millis: 1425991132134
OkHttp-Received-Millis: 1425991132581

9098-9332/com.comuto D/Retrofit﹕ java.io.EOFException
            at okio.RealBufferedSource.require(RealBufferedSource.java:64)
            at okio.GzipSource.consumeHeader(GzipSource.java:114)
            at okio.GzipSource.read(GzipSource.java:73)
            at okio.RealBufferedSource$1.read(RealBufferedSource.java:298)
            at retrofit.Utils.streamToBytes(Utils.java:43)
            at retrofit.Utils.readBodyToBytesIfNecessary(Utils.java:81)
            at retrofit.RestAdapter.logAndReplaceResponse(RestAdapter.java:483)
            at retrofit.RestAdapter.access$500(RestAdapter.java:107)
            at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:338)

Maybe ByteString.md5() and ByteString.sha256() would be sufficient.

It calls source.read(buffer, byteCount) which might not read byteCount bytes and also might return -1 (which is ignored).

Our API should make it hard to write buggy code, and this one tripped me up forcing use of the inverse API which correctly reported read count.

First of all, apologies for pointing out a problem with Android L, even though it is severely pre-prelease. I just ran into the following error related to okio, and thought you might have some insight on what might be happening here. It seems to run fine on the Dalvik VM.

            at okio.Buffer.writableSegment(Buffer.java:648)
            at okio.Buffer.writeByte(Buffer.java:581)
            at com.squareup.okhttp.internal.Platform.concatLengthPrefixed(Platform.java:410)
            at com.squareup.okhttp.internal.Platform$Android.setProtocols(Platform.java:249)
            at com.squareup.okhttp.Connection.upgradeToTls(Connection.java:179)
            at com.squareup.okhttp.Connection.connect(Connection.java:151)
            at com.squareup.okhttp.OkHttpClient$1.connect(OkHttpClient.java:84)
            at com.squareup.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:321)
            at com.squareup.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:241)
            at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:420)
            at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:371)
            at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:466)
            at com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
            at com.squareup.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)
            at retrofit.client.UrlConnectionClient.readResponse(UrlConnectionClient.java:73)
            at retrofit.client.UrlConnectionClient.execute(UrlConnectionClient.java:38)
            at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:321)
            at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:240)
            at java.lang.reflect.Proxy.invoke(Proxy.java:397)

http://tools.ietf.org/html/rfc4648#section-5

Suggested API:

String in;
assert in.equals(ByteString.decodeBase64Url(in).base64Url());

Guava equivalent:

BaseEncoding.base64Url().decode(...);
BaseEncoding.base64Url().encode(byteArray);

Our users are running into problems with java.nio.file.Path. We have proguard rules that help to work around this. We should document 'em.

See also #42

Hi,

Would you be willing to accept changes for a pluggable segment pool to make Okio more suitable for use in server environments with lots of concurrent buffer use?

Seems like this could be handy.

Installing with much effort the Spotify WEB API, using OkHttp, again using implicitly okio, I am trying to grasp the interrelation or overlap between these two APIs. I was halted for a day because I had not included the okio 1.2.0. jar in the build, and there were no build warning, and there were no sensible runtime error messages except this: "Retrofit.error: okio.Buffer". And then the Spotify WEB API went awry.

Hopefully, an improved error reporting system is on its way, but from where, okio or OkHttp or Retrofit?

Could anyone please explain this in 5 sentences? Many thanks.

(Spotify WEB API is now working, so all is fine)

As far as I can tell this will make implementing AsyncTimeout usage a lot easier.

I have a LocalSocket for which I want to gain the behavior of Okio.source(Socket) and Okio.sink(Socket) without having to write more than a few lines to hook up close() and getting the streams.

Formal methods found a bug in TimSort:
http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/

We could try out this software to check that tricky methods like Buffer.write satisfy their promises, specifically memory use.

I have a problem with using wire inside okio lib on new Android L developer preview. It's crashing with exception:
java.lang.IllegalAccessError: Illegal class access ('okio.Buffer' attempting to access 'okio.Util') in attempt to invoke static method void okio.Util.checkOffsetAndCount(long, long, long) (declaration of 'okio.Buffer' appears in /data/app/ru.advisa-1.apk)
at okio.Buffer.write(Buffer.java:554)
at okio.Buffer.write(Buffer.java:549)
at com.squareup.wire.WireInput.newInstance(WireInput.java:68)
at com.squareup.wire.Wire.parseFrom(Wire.java:124)
at ru.advisa.service.SyncNetworkOperationDelegate.doRequest(SyncNetworkOperationDelegate.java:95)
I think it related to new android runtime (art)

java.lang.NoSuchMethodError: No static method source(Ljava/net/Socket;)Lokio/Source; in class Lokio/Okio; or its super classes (declaration of 'okio.Okio' appears in /system/framework/okhttp.jar)

"Buffer" implements "BufferedSource" , "BufferedSource" extends "Source", "Source" depends on Buffer.It's a circle. in my opinion, it's not a good design pattern.Is there some good reason to do this?

Okio version 1.2.0.

Currently there does not seem to be a way to cleanly shut down the watchdog thread "Okio Watchdog" created by Okio AsyncTimeout. This results in the following warning when shutting down an application.

org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
WARNING: The web application [/] appears to have started a thread named [Okio Watchdog] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.lang.Object.wait(Native Method)
 java.lang.Object.wait(Object.java:460)
 okio.AsyncTimeout.awaitTimeout(AsyncTimeout.java:309)
 okio.AsyncTimeout.access$000(AsyncTimeout.java:40)
 okio.AsyncTimeout$Watchdog.run(AsyncTimeout.java:272)

I was looking for quick way to get size of my stream. So I've created method like this:

private long getSize(InputStream in) throws IOException {
    BufferedSource source = Okio.buffer(Okio.source(in));
    return source.readAll(Sinks.DEV_NULL_SINK);
}

Where Sink is empty implementation. I've wrote test for it:

public void testSize() throws Exception {
    ByteArrayInputStream bis = new ByteArrayInputStream(new byte[123000]);
    assertEquals(123000, getSize(bis));
}

and it fails with: junit.framework.AssertionFailedError: expected:<123000> but was:<3993720>. Documentation doesn't say that it might be valid behavior.

okio-1.2.0.jar is the latest JAR .But it does not contain the method “writeDecimalLong”

I tried to import okio-0.7.0.jar from Maven in my (eclipse) project but using Okio.source(InputStream) tells me it cannot compiled because of java.nio.file.Path cannot be resolved.

Switched to okio-0.6.1.jar and it's fine...

To extract a prefix, substring or suffix.

Sweep all public facing APIs for proper argument precondition checking (e.g., null rejecting, < 0 rejecting, etc.).

There's definitely a bunch missing in Buffer and the RealBuffered* classes.

In your README.MD: Download the latest JAR: http://repository.sonatype.org/service/local/artifact/maven/redirect?r=central-proxy&g=com.squareup.okio&a=okio&v=LATEST

I would like to ask you to shed light on SegmentPool dev plans. Currently it contains segments of equal size. Some time ago I implemented a pool of byte buffers based on a binary tree.
So I really have 2 questions:

1. do you think that binary tree implementation would work better than current linked list?
2. what would you measure to define this 'better'? :)

Both of these allocate a segment if necessary, but may end up not writing to that segment. We should write tests that exercise this situation and make sure we don't have a 0-byte segment still in a Buffer.

I have a problem with using okio lib on Android L OS.

I confirmed that HTTP header is created ordinarily before sending "HTTP GET" msg to server.

System.out: (HTTPLog)-Thread-1838-670551125: http socket connected to aaa.com/193.155.127.100:80 from /10.71.109.31:60059 with reading time out 0
System.out: (HTTPLog)-Thread-1838-670551125: connect() done, current connection is com.android.okhttp.Connection@3c35d8d1
System.out: (HTTPLog)-Thread-1838-670551125: transport is com.android.okhttp.internal.http.HttpTransport@da32f36
System.out: (HTTPLog)-Thread-1838-670551125: writeRequestHeaders GET /13i92/latest.txt HTTP/1.1

But, next step is fail. It's crashing with exception:

com.android.okio.Deadline.throwIfReached(Deadline.java:56)

System.err: java.io.InterruptedIOException
System.err: at com.android.okio.Deadline.throwIfReached(Deadline.java:56)
System.err: at com.android.okio.Okio$1.write(Okio.java:70)
System.err: at com.android.okio.RealBufferedSink.flush(RealBufferedSink.java:154)
System.err: at com.android.okhttp.internal.http.HttpConnection.flush(HttpConnection.java:126)
System.err: at com.android.okhttp.internal.http.HttpTransport.flushRequest(HttpTransport.java:80)
System.err: at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:775)
System.err: at com.android.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:379)
System.err: at com.android.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:323)
System.err: at com.android.okhttp.internal.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:190)
System.err: at java.net.URL.openStream(URL.java:470)

Hi,
when I come to proguard my project this error occurs:

Warning: okio.DeflaterSink: can't find referenced class org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement
Warning: okio.Okio: can't find referenced class java.nio.file.Files
Warning: okio.Okio: can't find referenced class java.nio.file.Files
Warning: okio.Okio: can't find referenced class java.nio.file.Files
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class java.nio.file.Path
Warning: okio.Okio: can't find referenced class java.nio.file.OpenOption
Warning: okio.Okio: can't find referenced class org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement

how can I solve the problem?

socket source should not use -1 to determine if stream had been read to end. Buffer.readByteArray, readFull etc will throw SocketTimeoutException.

• Readme: positive language
• toAsciiUpperCase()
• Buffer.writeTo(OutputStream) #22
• Buffer.readFrom(InputStream) #22
• Motivations: driven by OkHttp

I'm currently using okhttp to handle network requests, but occasionally it crashes with the following. I can't seem to find anyone else with this issue, nor can I reproduce it reliably. Is this a situation where I should be setting request timeouts explicitly within okhttp, or is this an actual issue with okio?

If this should be an okhttp issue, let me know and I can post it there instead.

java.lang.IllegalStateException: No deadline
        at okio.Timeout.deadlineNanoTime(Timeout.java:104)
        at okio.AsyncTimeout.scheduleTimeout(AsyncTimeout.java:88)
        at okio.AsyncTimeout.enter(AsyncTimeout.java:69)
        at okio.AsyncTimeout$2.read(AsyncTimeout.java:209)
        at okio.RealBufferedSource.exhausted(RealBufferedSource.java:60)
        at com.squareup.okhttp.internal.http.HttpConnection.isReadable(HttpConnection.java:152)
        at com.squareup.okhttp.Connection.isReadable(Connection.java:305)
        at com.squareup.okhttp.OkHttpClient$1.isReadable(OkHttpClient.java:87)
        at com.squareup.okhttp.internal.http.RouteSelector.nextUnconnected(RouteSelector.java:143)
        at com.squareup.okhttp.internal.http.RouteSelector.next(RouteSelector.java:130)
        at com.squareup.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:312)
        at com.squareup.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:235)
        at com.squareup.okhttp.Call.getResponse(Call.java:262)
        at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:219)
        at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:192)
        at com.squareup.okhttp.Call.access$100(Call.java:34)
        at com.squareup.okhttp.Call$AsyncCall.execute(Call.java:156)
        at com.squareup.okhttp.internal.NamedRunnable.run(NamedRunnable.java:33)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:818)

BufferedSource designed to use against InputStream but since BufferedSource loads entire data in memory, it cannot be used to read big files.
It would be great if BufferedSource can really buffer some chunk of data instead of whole file.

Since Okio complements java.io and nio I really thought BufferedSource is an replacement/option to java's BufferedReader.

Example I was trying : https://gist.github.com/premrajm/c5f012ced316b7de17b1