Archivo de la etiqueta: kotlin

try-with-resources en Kotlin

EDITADO (7/4/2017): según comentan en StackOverflow, Kotlin 1.1 soporta try-with-resources en su librería estándar para Java 8

Una de las grandes novedades que nos trajo Java 7 fue el soporte para try-with-resources, que nos permitía definir bloques que, utilizando un recurso que implementara la interfaz “AutoCloseable“, cerraban éste implícitamente sin tener que preocuparnos de llamar a su método “close()“. Por ejemplo:

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
   return br.readLine();
}

Kotlin provee una solución equivalente para los objetos del tipo “Closeable“, que es la función “use“:

BufferedReader(FileReader("dsf")).use {
    it.readLine()
}

Sin embargo, parece que los creadores de Kotlin se han olvidado de las clases AutoCloseable, tales como los PreparedStatement de JDBC. Para solucionarlo, he creado una función trywr, fácilmente integrable en cualquier código

package info.macias.kotlin
inline fun <T:AutoCloseable,R> trywr(closeable: T, block: (T) -> R): R {
    try {
        return block(closeable);
    } finally {
        closeable.close()
    }
}

Un ejemplo de uso sencillo:

import info.macias.kotlin.trywr
fun countEvents(): Long {
    return trywr(connection.prepareStatement("SELECT COUNT(*) FROM event")) {
        var rs = it.executeQuery()
        rs.next()
        rs.getLong(1)
    }
}

No obstante, me comentan en Stackoverflow que aunque la solución es sencilla y hará su función, no reproducirá exactamente el comportamiento estándar de Java.

Integrando Kotlin en aplicaciones web

Java, pese a las impresionantes mejoras que trae en su versión 8, siempre me ha parecido un lenguaje un poco verboso y con algunas incomodidades con respecto a C#.

Lenguajes como Python, Ruby o ECMAScript son cómodos y ágiles, pero no me gustan para proyectos de cierta envergadura puesto que, siendo tan despistado como soy, prefiero lenguajes con tipado estático que me muestren los errores en tiempo de compilación y ahorrarme tener que buscarlos con el depurador.

Groovy es un gran lenguaje, aunque un tanto lento. A la filosofía Scala no me he acabado de acostumbrar, y siempre acabo haciendo programas con la misma estructura que si de un programa Java se tratara. Además, he tenido algunos problemas tratando de integrar Scala con librerías Java.

A pesar de las críticas que programadores “new age” lanzan por una cuestión de moda, me gusta la Máquina Virtual de Java y el impresionante número de librerías y frameworks maduros que posee. No cambiaría para irme a Rails o Node, a pesar de sus muchas otras ventajas. Quizás la cambiaría para irme a .NET si éste finalmente llega a ser completamente multiplataforma (otro sacrilegio, no solo para programadores “new age”  si no también para aquellos que asocian automáticamente Microsoft con malvado y malo).

Durante estas vacaciones he tenido tiempo de probar por encima Kotlin, y la verdad es que las primeras impresiones han sido buenas. Principalmente, me ha gustado, entre otras:

  • Es estáticamente tipado
  • Le quita verbosidad a Java
  • Getters y setters directamente definidos en los atributos, y no como métodos (al estilo de C# o Groovy)
  • Null safety
  • Sobrecarga de operadores al estilo de C++
  • Data classes
  • Lo extremadamente bien que se integra con las librerías existentes de Java
  • El soporte de Jetbrains le da en su IDE, incluida la funcionalidad de traducir automáticamente código Java a Kotlin

Como demostración (y para mi utilidad propia en aplicaciones futuras), he creado este pequeño proyecto web que integra Kotlin con algunas librerías para el desarrollo web, tales como Struts 2 y Tiles para la gestión del Modelo Vista Controlador, Shiro para la gestión de la seguridad, y Jersey para la implementación de servicios REST.

El enlace en cuestión, con sus respectivas instrucciones de puesta en marcha: https://github.com/mariomac/kwebbt