Roadmap for 1.0

[quelgar]

What milestones do we need to hit to reach 1.0?

• The main 1.0 feature is generally a commitment to not break backwards compatibility of the API, so we want to have the core API locked in.
• Use ZManaged for all resource management. Many NIO objects require strict lifecycle management using error-prone methods like close and release, it would be great to use ZManaged instead (Use ZManaged for resource management #30)
• The microsite (already in progress Create microsite using mdoc #15 Create microsite #20)
• A reasonable level of Scaladoc.
• Wrap DatagramChannel (DatagramChannel wrapper #56)
• Use ZIO's executor for AsynchronousChannelGroup (Make AsynchronousChannelGroup use ZIO's Executor #29)
• Wrapping of the java.nio.file package (Wrapping of the java.nio.file package #27 in progress by @quelgar)
• Support for Scala 2.13 (and maybe 2.11)

Add more or throw out ideas in the comments!

[mijicd]

I'd add 2.13 (maybe 2.11) compatibility as well.

[quelgar]

Another thing I've been thinking about is if we can improve type safety in other areas:

Read-only buffers: The Buffer wrappers currently mimic the Java API with regard to read-only buffers. You can have buffers in a read-only "mode" where all the write APIs are still there, but throw ReadOnlyBufferException if you call them by accident. How about having a trait just with read operations for these read-only variants?

SelectableChannel: A problem with SelectableChannel subtypes (network channels and pipes) is that they can be switched to non-blocking mode. The difference between these modes is pretty significant for a ZIO program. I'm thinking we could have two variants of all SelectableChannels: a blocking version with ZIO's Blocking required: ZIO[Blocking, Exception, X], and a non-blocking using ZIO[Any, Exception, X].

[quelgar]

A more philosophical question is whether we want to add any extra convenience utilities in zio-nio.

As an example, consider the java.nio.file.Files#copy methods that use InputStream or OutputStream. The functionality of splatting a stream of bytes to a file seems with minimal fuss seems generally useful, but the Java NIO implementations don't seem at all useful to a ZIO program. What we really want is something like:

def copy(in: ZStreamChunk[Blocking, Exception, Byte], target: Path, options: CopyOption*): ZIO[Blocking, Exception, Long]

But implementing this by wrapping the Java equivalent is quite difficult. It would be easier and likely more performant to simply implement it ourselves using our FileChannel wrapper. But that arguably goes beyond the zio-nio mission statement A small, unopinionated ZIO interface to NIO.. So perhaps we just don't offer any of the NIO utility methods that don't work well for ZIO.

[pshemass]

do you think we should also include support for sun.misc.Unsafe ? OffHeapMemory might be pretty useful

[jczuchnowski]

But that arguably goes beyond the zio-nio mission statement A small, unopinionated ZIO interface to NIO.. So perhaps we just don't offer any of the NIO utility methods that don't work well for ZIO.

@quelgar or we could create a subproject with NIO utilities and "unclean" implementations. Could be distributed as a separate dependency and used by those who want it, leaving the ZIO-NIO core unopinionated.

[pshemass]

@quelgar should we add to the list wrapper for DatagramChannel?

What is missing in terms of java.nio api?

[quelgar]

do you think we should also include support for sun.misc.Unsafe ? OffHeapMemory might be pretty useful

Definitely seems useful, but perhaps that's something that belongs in interop-java?