He refactorizado estos días el método siguiente, con el objeto de usar las nuevas lambdas de Java 8

public static Map<Object, Object> getProperties(JComponent component) {
final Method[] methods = component.getClass().getMethods();
final Map<Object, Object> retVal = new HashMap<>(Numbers.getMapCapacity(methods.length));
for (Method method : methods) {
if (method.getName().matches("^(is|get).*") && method.getParameterTypes().length == 0) {
try {
final Class<?> returnType = method.getReturnType();
if (returnType != void.class && !returnType.getName().startsWith("[") && !setExclude.contains(method.getName())) {
final Object value = method.invoke(component);
if (value != null && !(value instanceof Component)) {
retVal.put(method.getName(), value);
}
}
// ignore exceptions that arise if the property could not be accessed
} catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
}
}
}
return retVal;
}

Finalmente, el nuevo método ha quedado como sigue. Como aquí no se puede dar un formato adecuado al código, he separado las funciones con un espacio en blanco, para facilitar la lectura.

public static Map<String, Object> getProperties(final JComponent component) {
return Arrays

.stream(component.getClass().getMethods())

.filter((Method method) -> method.getName().matches("^(is|get).*") && method.getParameterTypes().length == 0)

.filter((Method method) -> {
final Class<?> returnType = method.getReturnType();
return returnType != void.class && !returnType.getName().startsWith("[") && !setExclude.contains(method.getName());
})

.map((Method method) -> {
Method methodMapped = null;
try {
Object value = method.invoke(component);
if (value != null && !(value instanceof Component)) {
methodMapped = method;
}
} catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
}
return methodMapped;
})

.filter((Method method) -> method != null)

.collect(Collectors.toMap(
Method::getName,
(Method method) -> {
Object value = null;
try {
value = method.invoke(component);
} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException ex) {
}
return value;
}));
}

Es indudable el aumento significativo en las líneas de código. Aunque es comprensible, dados los tres if encadenados, con una variable de control en medio, y las excepciones.
Me parece que el código es más comprensible ahora, porque la secuencia lógica es lineal.
Aunque es un caso especial (normalmente el uso de lambdas no implica aumentos tan evidentes de la extensión del código), me gustaría conocer opiniones al respecto.

No sé si como noticia será bien aceptado. Es un caso muy concreto de refactorización.
Quizás podría mencionarse en Noticias esta entrada en el foro, invitando a abrir un debate sobre lambdas en el mismo foro, y ver qué pasa.
Ya cansa un poco que el foro sea solo un "solucionario de problemas" :)

Es cuestión de acostumbrarse. No me ha llevado tanto tiempo ni esfuerzo, porque antes ya había realizado un centenar de refactorizaciones a lambdas, por lo que leo sin esfuerzo las funciones.
El caso es complejo, debido a un for y tres if con condiciones intermedias, aderezado con las excepciones.
Estando habituado a la programación imperativa, es normal que se lea mejor que la funcional; pero no porque la primera sea más clara, sino por simple hábito mental.
Sin embargo, una vez acostumbrado a lo que significa cada función, y lo que devuelve, el nuevo código se lee y se comprende de un tirón, leyéndolo tal y como está escrito: linealmente.
Creo que esa es una de las grandes ventajas de la programación funcional.

También es cierto que sin un formato adecuado, apenas se entiende nada :)
Lástima que el foro no lo permita.

Podría publicar el caso inverso, donde la refactorización a lambdas ha reducido el volumen de código a menos de una cuarta parte, y la comprensión ha aumentado varios órdenes de magnitud: de implementaciones directas de Fork/Join a Lambas.

El for se reemplaza por stream
Los tres if se reemplazan por dos filter y un map
Se añade un filter adicional para evitar posibles null en el retorno del map
El collect final crea y llena el Map resultante

En realidad es lo mismo (excepto ese filter adicional) resuelto de otra manera, porque el resto del código es casi idéntico.
En este caso, las excepciones no se pueden lanzar como con los métodos, porque los lambdas no lo permiten; de ahí esas excepciones capturadas que añaden líneas al código.
Si un componente tiene muchas propiedades, el stream se puede paralelizar, lo que añadiría un mejor rendimiento.
Cuando leo el segundo código, entiendo mejor lo que sucede, porque no tengo que realizar saltos mentales para seguir la ejecución, inevitables en la solución imperativa.
A fin de cuentas, el código fuente se escribe para que lo entiendan seres humanos :)