hypirion / com.hypirion.io Goto Github PK

Well, we don't love it, but certainly, having something that can prove that the race conditions doesn't appear would be nice.

One requirement for licensing code under the EPL is that "a copy of this Agreement [the EPL] must be included with each copy of the Program." [0]. Unfortunately io does not comply with this requirement even though its project.clj claims that it is licensed under the EPL.

Additionally it would be nice if every source file could mention its license explicitly. That is it should include a statement of copyright and, for the EPL, a header such as:

THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.

Please fix this issue and release a new version of io as it is not legally distributable in its current form.

[0] http://www.eclipse.org/legal/epl-v10.html → 3. REQUIREMENTS

RevivableInputStream is currently reading a single byte per read. Having the possibility for a buffer in this class should speed up reading lots of data.

Pipes are a convenient way to handle data transfer from an InputStream to an OutputStream, and should be added in to the library. While large libraries like Apache Commons has some features like this, using a full-blown library full of convenience functions for just one method seems unnecessary. In addition, some features such as pausing, stopping and resuming such pipes aren't currently available there.

Thanks for putting this library together. Given that Bintray has shut down, do you have any plans to publish this library on Maven Central?

Should be self-explanatory: Document how and what each method in these classes work.

There are many cases where you would love to wrap an output stream or writer, but want to tag each line in the output with some specific prefix. It seems easy at first, but many subtleties pop up: You have to take carriage-return into consideration, handle different system newlines, figure out what do to when .close or .flush is called, and so forth.

There's a problem with RevivableInputStream.read():
return b[0];

This returns signed byte as int -- i.e. it can return negative value -- which is interpreted by clients as EOF -- as per spec.

The proper code is something like this:
return Byte.toUnsignedInt(b[0]);

There's no need to not have an option to the original Pipe class. Granted, a setClosing should only be invoked once (somehow), and that before starting the pipe. Such design issues should be considered before we start hacking on it.

Currently, System.console() relies on a self-designed reader which cannot be changed at all. Having the possibility the replace it at runtime would be nice, esp. if you replace System.in with a revivable input stream.

Goes without saying, this one. Better explain how to add this to your lovely maven pom, since the repo isn't maven central.