Estoy jugando con las nuevas funciones lambda en Java 8, y encontré que las prácticas ofrecidas por Java 8 son realmente útiles. Sin embargo, me pregunto si hay unbueno manera de hacer una solución para el siguiente escenario. Supongamos que tiene un contenedor de grupo de objetos que requiere algún tipo de fábrica para llenar el grupo de objetos, por ejemplo (usandojava.lang.functions.Factory):

public class JdbcConnectionPool extends ObjectPool<Connection> {

    public ConnectionPool(int maxConnections, String url) {
        super(new Factory<Connection>() {
            @Override
            public Connection make() {
                try {
                    return DriverManager.getConnection(url);
                } catch ( SQLException ex ) {
                    throw new RuntimeException(ex);
                }
            }
        }, maxConnections);
    }

}

Después de transformar la interfaz funcional en la expresión lambda, el código anterior se convierte así:

public class JdbcConnectionPool extends ObjectPool<Connection> {

    public ConnectionPool(int maxConnections, String url) {
        super(() -> {
            try {
                return DriverManager.getConnection(url);
            } catch ( SQLException ex ) {
                throw new RuntimeException(ex);
            }
        }, maxConnections);
    }

}

No está tan mal, pero la excepción comprobadajava.sql.SQLException requiere untry/catch Bloque dentro de la lambda. En mi empresa utilizamos dos interfaces durante mucho tiempo:

IOut<T> eso es un equivalente ajava.lang.functions.Factory;y una interfaz especial para los casos que normalmente requieren la propagación de excepciones comprobadas:interface IUnsafeOut<T, E extends Throwable> { T out() throws E; }.

AmbosIOut<T> yIUnsafeOut<T> se supone que deben eliminarse durante la migración a Java 8, sin embargo, no hay una coincidencia exacta paraIUnsafeOut<T, E>. Si las expresiones lambda pudieran lidiar con las excepciones marcadas como si no estuvieran marcadas, podría ser posible usar simplemente lo siguiente en el constructor de arriba:

super(() -> DriverManager.getConnection(url), maxConnections);

Eso se ve mucho más limpio. Veo que puedo reescribir elObjectPool super clase para aceptar nuestraIUnsafeOut<T>, pero por lo que sé, Java 8 aún no está terminado, por lo que podría haber algunos cambios como:

implementando algo similar aIUnsafeOut<T, E>? (Para ser honesto, lo considero sucio: el sujeto debe elegir qué aceptar: o bienFactory o "fábrica insegura" que no puede tener firmas de métodos compatibles)simplemente ignorando las excepciones marcadas en lambdas, por lo que no es necesario enIUnsafeOut<T, E> sustitutos? (¿Por qué no? Por ejemplo, otro cambio importante: OpenJDK, que utilizo,javac Ahora no requiere que las variables y parámetros sean declarados comofinal para ser capturado en una clase anónima [interfaz funcional] o expresión lambda)

Entonces, la pregunta en general es: ¿hay una manera de evitar las excepciones marcadas en lambdas o se planea en el futuro hasta que finalmente se lance Java 8?

Actualización 1

Hm-m-m, hasta donde entiendo lo que tenemos actualmente, parece que no hay manera en este momento, a pesar de que el artículo de referencia está fechado en 2010:Brian Goetz explica la transparencia de excepción en Java. Si nada cambió mucho en Java 8, esto podría considerarse una respuesta. También Brian dice queinterface ExceptionalCallable<V, E extends Exception> (lo que mencione comoIUnsafeOut<T, E extends Throwable> fuera de nuestro código legado) es bastante inútil, y estoy de acuerdo con él.

¿Todavía echo de menos algo más?