¿Hay una manera concisa para crear un InputSupplier de un InputStream en Google guayaba?

Question

Existen algunos métodos de fábrica en Google guayaba para crear InputSuppliers, por ejemplo, de un byte[]:

ByteStreams.newInputStreamSupplier(bytes);

O de una File:

Files.newInputStreamSupplier(file);

¿Hay una manera similar a la de crear un InputSupplier para un InputStream dado?

Es decir, una manera que es más conciso que una clase anónima:

new InputSupplier<InputStream>() {
    public InputStream getInput() throws IOException {
        return inputStream;
    }
};

Fondo: Me gustaría utilizar InputStreams con, por ejemplo, Files.copy(...) o ByteStreams.equal(...).

Answer 1

No, no he visto nada.
creo que haya encontrado la mejor manera.
La única alternativa dónde almacenar el flujo de entrada en una matriz de bytes o un archivo y crear un proveedor con ByteStreams.newInputStreamSupplier () o Files.newInputStreamSupplier (), pero me desanimaría a hacerlo así.
También es posible usar

public static long copy(InputStream from, OutputStream to)

de

ByteStreams

ver: src

Answer 2

No hay manera de convertir un InputStream arbitraria en un InputSupplier<InputStream>, porque un InputSupplier<InputStream> se supone que es un objeto que puede crear una nueva y fresca InputStream cada vez que su método se llama getInput(). Esto sólo es posible cuando la fuente subyacente de bytes está disponible para su reutilización; por lo tanto, los métodos de fábrica que toman un byte[] o File y devolver una InputSupplier<InputStream>.

Como sugiere Dimitris, InputSupplier refiere a InputStream de la misma manera que Iterable refiere a Iterator. La clase anónima que usted describe es incorrecta, ya que devuelve el mismo transmitir cada vez que getInput() se llama, por lo que las invocaciones posteriores devolverá un InputStream que ya está agotado y cerrado.

Aquí hay otro problema con su clase anónima: parte de la motivación para InputSupplier es limitar la visibilidad de la InputStream real, de modo que se puede cerrar de forma automática. Si envuelve una InputStream visible desde el exterior en un InputSupplier y luego pasa que en un método de utilidad, el método de utilidad puede cerrar su InputStream. Es posible estar bien con eso, pero eso no es un patrón de uso que limpia guayaba querría promover.

Cuando me encontré que quieran hacer lo mismo, me di cuenta de que lo estaba haciendo al revés. En vez de hacer esto:

Files.copy(InputSupplier.of(inputStream), destinationFile);

(no existe), que en su lugar debería estar haciendo esto:

ByteStreams.copy(inputStream, Files.newOutputStreamSupplier(destinationFile));

Answer 3

Eso sería tan erróneo como envolver un iterador a un Iterable, siento que hay al igual que la probabilidad cero de tal cosa de entrar en la biblioteca. Como elou dice, puede utilizar el método ByteStreams.copy (), pero no parece ser una razón obvia de hacer iguales () en dos corrientes.

entiendo autores de guayaba vacilación método (trivial) para añadir Tal - ¿Qué tan común que puede ser para completamente (o parcialmente, pero sin saber dónde se salió de la corriente, por lo que es tan bueno como inservible después) leyó dos corrientes sólo para ver si son los mismos, sin ningún otro tratamiento de los datos? ¿Estos bytes proceden de una fuente no repetible-lectura, como una toma de red? De lo contrario, si es sólo un archivo en alguna parte, o una matriz de bytes en memoria, hay otras maneras que se prestan a hacer una prueba de igualdad.