Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ByteString conversions for JVM ByteBuffer #269

Closed
joffrey-bion opened this issue Feb 26, 2024 · 5 comments
Closed

Add ByteString conversions for JVM ByteBuffer #269

joffrey-bion opened this issue Feb 26, 2024 · 5 comments
Labels
Design enhancement integration An issue related to the integration with other libraries or platform-specific APIs

Comments

@joffrey-bion
Copy link

joffrey-bion commented Feb 26, 2024

In the same vibe as #266 and #268, it would be nice to have built-in conversions in kotlinx-io-bytestring for the JVM ByteBuffer type for a full multi-platform experience.

Examples:

/**
 * Exposes the contents of this [ByteString] as a read-only [ByteBuffer] without copying data.
 */
fun ByteString.asReadOnlyByteBuffer(): ByteBuffer = ByteBuffer.wrap(getBackingArrayReference()).asReadOnlyBuffer()

/**
 * Reads all remaining bytes in this [ByteBuffer] into a new [ByteString].
 */
fun ByteBuffer.readByteString(): ByteString = ByteString.wrap(readByteArray())

/**
 * Reads all remaining bytes in this [ByteBuffer] into a new [ByteArray].
 */
// private because that's not really the role of kotlinx-io-bytestring, more of the stdlib
private fun ByteBuffer.readByteArray(): ByteArray {
    val array = ByteArray(remaining())
    get(array)
    return array
}

Arguably the last one could be a stdlib function instead.

@joffrey-bion
Copy link
Author

joffrey-bion commented Feb 26, 2024

Note: this might slightly overlap with #239, but I still believe it's a different use case, and much easier to add. This is less about using ByteBuffer internally, nor about being able to wrap those directly as backing storage, but more about being able to interop with it conveniently.

@fzhinkin fzhinkin added enhancement Design integration An issue related to the integration with other libraries or platform-specific APIs labels Feb 26, 2024
@fzhinkin
Copy link
Collaborator

fzhinkin commented Sep 4, 2024

@joffrey-bion We already have set of functions wrapping Sinks, Sources, and Buffers into Channels, as well as functions allowing to read/write Buffer from/to ByteBuffer. And there doesn't seem to be a lot of adoption.

Are there any scenarios where proposed functions could be used indeed? Would existing NIO-centric extensions work there?

@joffrey-bion
Copy link
Author

Are there any scenarios where proposed functions could be used indeed?

Yes, this is also something I use in Krossbow to wrap the Java web socket APIs.

Would existing NIO-centric extensions work there?

Which extensions are you referring to? In my case the goal is to bridge ByteBuffers (that I get from Java APIs) to ByteStrings (that I expose in my Kotlin API) in the most efficient way.
It could be ok to go through other intermediate representations if this didn't incur more copies than necessary.

@fzhinkin
Copy link
Collaborator

fzhinkin commented Sep 5, 2024

Which extensions are you referring to?

It could be ok to go through other intermediate representations if this didn't incur more copies than necessary.

But yeah, the use of any of those from above implies additional copies. :(

@joffrey-bion
Copy link
Author

Thanks! Ok that was my understanding, so yeah I would still need these more direct helpers then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design enhancement integration An issue related to the integration with other libraries or platform-specific APIs
Projects
None yet
Development

No branches or pull requests

2 participants