// the find
lysine-dev/okio
A modern I/O library for Android, Java, and Kotlin Multiplatform.
Okio is the buffer and byte I/O library that OkHttp started out as a component of, now built as a Kotlin Multiplatform project with JVM, Android, JS, Wasm, and Apple targets. It is for library and app authors who want one Source, Sink, and ByteString API across those platforms instead of maintaining separate java.io and platform-specific code paths. The README is thin, so most of the evaluation has to come from the source tree.
Buffer and Segment live in commonMain, so the same segmented buffer and ByteString code runs on every target, and SegmentPool reuses segments instead of allocating on every read and write. The filesystem backends are separate modules (okio-nodefilesystem, okio-wasifilesystem, okio-assetfilesystem), so a JVM-only or JS-only consumer doesn't pull in the rest, and okio-fakefilesystem gives tests an in-memory FileSystem. okio.api and okio.klib.api are checked in, so binary and klib API changes show up as diffs in review instead of surprising downstream users. The JMH suite covers Buffer, UTF-8, hashing, ByteString, and select, so performance claims about changes here can be measured rather than argued.
The README has no code sample and sends all documentation to an external site, even though the repo ships docs/recipes.md and docs/file_system.md. Someone deciding whether to adopt it learns nothing from the front page. ExperimentalFileSystem.kt in commonMain suggests the FileSystem API is still behind an opt-in marker, so building on it means accepting API churn. Test coverage is uneven by the file tree: okio-nodefilesystem has a single test file, and AssetFileSystem's only test is an Android instrumented test that needs a device or emulator. The README links to lysine-dev/okhttp and says nothing about how this repo relates to Square's upstream okio, so check the Maven coordinates before depending on it.