¿Por qué no usa más código Java PipedInputStream / PipedOutputStream?

Descubrí este idioma recientemente, y me pregunto si hay algo que me falta. Nunca lo he visto usado. Casi todo el código Java con el que he trabajado favorece la extracción de datos en una cadena o búfer, en lugar de algo como este ejemplo (usando HttpClient y API de XML, por ejemplo):

    final LSOutput output; // XML stuff initialized elsewhere
    final LSSerializer serializer;
    final Document doc;
    // ...
    PostMethod post; // HttpClient post request
    final PipedOutputStream source = new PipedOutputStream();
    PipedInputStream sink = new PipedInputStream(source);
    // ...
    executor.execute(new Runnable() {
            public void run() {
                output.setByteStream(source);
                serializer.write(doc, output);
                try {
                    source.close();
                } catch (IOException e) {
                    throw new RuntimeException(e);
                }
            }});

    post.setRequestEntity(new InputStreamRequestEntity(sink));
    int status = httpClient.executeMethod(post);

Ese código utiliza una técnica de estilo de tubería Unix para evitar que se guarden en la memoria varias copias de los datos XML. Utiliza la secuencia de salida HTTP Post y la API DOM Load / Save para serializar un documento XML como el contenido de la solicitud HTTP. Por lo que puedo decir, minimiza el uso de memoria con muy poco código adicional (solo las pocas líneas paraRunnable, PipedInputStreamyPipedOutputStream)

Entonces, ¿qué tiene de malo este idioma? Si no hay nada de malo en este idioma, ¿por qué no lo he visto?

EDITAR: para aclarar,PipedInputStream yPipedOutputStream reemplace la copia repetitiva buffer-by-buffer que aparece en todas partes, y también le permiten procesar los datos entrantes simultáneamente con la escritura de los datos procesados. No usan tuberías del sistema operativo.

Respuestas a la pregunta(8)

Su respuesta a la pregunta