Cómo aplicar corriente <E> y sin una advertencia de pérdida de recursos en Java

Nikolas:

Deseo poner en práctica el Stream<E>interfaz (lo admito, es el tamaño excesivamente grande uno) y añadir un método constructor foo().

public MyStream<E> implements Stream<E>, ExtendedStream<E> {

    private final Stream<E> delegate;

    public MyStream(final Stream<E> stream) {
        this.delegate = stream;
    }

    // a sample Stream<E> method implementation
    @Override
    public <R> MyStream<R> map(Function<? super E, ? extends R> mapper) {
        return new MyStream<>(this.delegate.map(mapper));
    }
    // the rest in the same way (skipped)

    // a method from ExtendedStream<E>
    @Override
    public MyStream<E> foo() {
        return new MyStream(this.delegate.......);
    }  
}

Hasta aquí todo bien.

long count = new MyStream(list.stream())
    .map(i -> i * 10)
    .foo()
    .filter(i -> i > 100)
    .count();

Tengo problemas con el Closeablecomportamiento de Stream. La documentación de los Streamdice acerca de cierre (mina de formateo):

Corrientes tienen un BaseStream.close()método y poner en práctica AutoCloseable, pero casi todos los casos de transmisión en realidad no tienen que ser cerrado después de su uso. Generalmente, solamente corrientes cuya fuente es un canal de IO (como los devueltos por Files.lines(Path, Charset))requerirá cierre.

Los únicos métodos que son cerca Stream flatMapo close.

La instanciación de un objeto en Eclipse oxígeno está subrayado con una advertencia:

Pérdida de recursos: ' <unassigned Closeable value>' no se cierra nunca

Esto no es reproducible con IntelliJ IDEA 01/05/2018 . Preguntas relacionadas Me desnatada a través están aquí y aquí . Entiendo los Closeableproblemas con Fileo Dictionary, sin embargo, estoy atascado con corrientes.

^{No me gusta el método estático MyStream.of(...)llamar a una solución constructor privado.}

Stephan Herrmann:

Como parte del trabajo en JSR 335 , las bibliotecas JRE evolucionaron mediante la introducción java.util.Streamy al mismo tiempo aprovechar el nuevo concepto en lugares como java.nio. Durante este tiempo, el equipo Eclipse fue consultado por el grupo de expertos JSR 335, para discutir el siguiente conflicto :

• Herramientas como ecj quieren señalar cuando los programadores se olvidan de cerrar un recurso GC-resistente (GCR) como, por ejemplo, una FileInputStream.

• El equipo de la biblioteca planeado hacer java.util.Streamun subtipo de AutoCloseablehabilitar el uso de try-con-recursos, motivado por el hecho de que una j.u.Streampodría potencialmente ser respaldada por un recurso GCR. Aún así, el supuesto defecto debe ser que los casos de j.u.Streamno no requieren una close()llamada.

• Sin embargo, ciertos métodos en java.niovolver j.u.Stream requieren ser close()d.

EG y Eclipse estuvieron de acuerdo en que hay una solución fácil se pudo encontrar tal manera que con sólo mirar el tipo de que se pueda cerrar cualquier herramienta podría reconocer con precisión si el cierre es necesario o no. Esto es debido a complejidades de los diversos recursos que envuelven otros recursos en varios niveles. En particular, el tipo j.u.Streamno da ninguna indicación de si o no casos están respaldados por los recursos de GCR o no.

Para una soluation limpio, se mencionó, además, que sería necesario un sistema de anotaciones de tipo (utilizando JSR 308) para enriquecer el sistema de tipos con la información necesaria para el análisis estático preciso. A lo mejor de mi conocimiento, este enfoque no se ha materializado hasta hoy.

Como solución de compromiso, ejecutores herramienta como Eclipse se les aconsejó a la heurística codifican a lo largo de las siguientes líneas:

• Normalmente, todas las instancias de tipo AutoCloseabledeben estar cerrados.

• El siguiente conjunto conocido de tipos debía ser excluido del análisis, porque los que normalmente no requieren el cierre: java.util.Streamy {Int,Long,Double}Stream.

• Como una excepción de la excepción, cierta corriente de retorno de los métodos estáticos en java.niose sabe que requieren cierre.

La discusión básicamente pasó entre los dos puestos siguientes en las lambda-libs-SPEC-observadores lista de correo:

• planteamiento del problema de Brian y propuesta intermedia

• Mi resumen de una conversación privada .

Esto en cuanto a la historia.

La discusión en el año 2013 no cuenta para implementaciones personalizadas de j.u.Stream. Eclipse no asume ningún conocimiento específico sobre esas implementaciones. Sería mejor, si no la herramienta decidiría un sesgo hacia la necesidad / no necesitar close (), pero si el implementador (en este caso de MyStream) tendría los medios para indicar, si las instancias de esta clase requieren el cierre o no. Hasta la fecha los ejecutores tienen, sin embargo, ningún medio para expresar esto.

A falta de una propuesta completa y precisa, podríamos discutir extender el conjunto de heurísticas, de tal manera que no sólo el conjunto conocido de tipos en la j.u.Streamfamilia, sino también a todos sus subtipos se excluyen del análisis, y que se consideran GC-amigable. Obviamente, este enfoque podría aumentar el riesgo de falsos negativos (errores pasados por alto por el análisis).

Marcado advertencias como "posibles fugas", como lo sugiere la respuesta de howlger podría ser confuso, ya que en el análisis de flujo, la palabra "potencial" normalmente debería indicar un comportamiento que se produce en algunos, pero no todos, fluye a través del programa.

Las opciones disponibles a partir de hoy son:

• Uso de @SuppressWarnings("resource")donde MyStreamse utiliza (preferible)

• La reducción de la gravedad de este problema en particular (si el uso de MyStreamse extiende demasiado ancha para utilizar la primera opción).