Que esperar/aprender de Java en 2020

Yo, en una foto donde me veo bien profético

Inicio el año con seis predicciones para Java en 2020. A diferencia del difunto Walter Mercado la mayoría no son resultado de ver las estrellas. Más bien son el resultado de patrones que observé en 2019 en la industria, clientes, conferencias y creo que se consolidaran en este año.

1. Java 11 finalmente se masificara

Uno de los mayores problemas con la aparición de Java 9 fue la introducción de JPMS o «Java modules». Diferente de otras versiones de Java esto creó un mar de bugs porque entre otras cosas ocultó el paquete sun.misc.unsafe utilizado por varias bibliotecas importantes.

Aunque pareciera poco importante que una biblioteca no tenga acceso a un paquete o a una característica, impacta en cascada a los usuarios de la biblioteca, que eventualmente impacta a los frameworks, que eventualmente impacta a los runtimes, que eventualmente impactan a los «developers callejeros» que utilizan estos frameworks. Toda una pesadilla.

En 2019 observé sin embargo que los grandes runtimes Java empezaron a dar soporte oficial a Java 11 ya sea como primicia o como consolidación de lo presentado durante 2018, algunos de los más importantes de los que uso en mi día a día:

  1. Tomcat
  2. Jetty
  3. JavaFX
  4. Spring Boot
  5. Wildfly
  6. Payara (ex. Glassfish)
  7. Open Liberty

Probablemente el ultimo en unirse al grupo sera WebLogic que ya tiene una versión beta con Java 11, más vale tarde que nunca :).

2. La pelea en el Java moderno se dará en el campo AOT

Uno de los mayores deseos de las bibliotecas Java hoy en día es declararse «compatible con GraalVM AOT» lo que significa que la biblioteca es compatible con la generación de binarios nativos para Linux (y Mac).

Aunque los binarios AOT son relativamente más lentos que la ejecución de bytecode sobre una JVM con JIT, en el mundo de los microservicios y sobre todo en serverless suele quedar en segundo plano frente a la velocidad de «cold start».

En esta linea Quarkus, Helidon y Micronaut lideran indiscutiblemente. Curiosamente 2 de estos 3 son compatibles con MicroProfile, ¿quien lo diría hace unos años?.

En Latinoamérica probablemente seguirá la tendencia de Spring, pero en el resto del mundo creo que su dominio finalmente se ve amenazado. Sin contar que la recompra por parte de VMWare puede traer efectos a mediano plazo sobre Spring.

3. Kotlin pasara 2020 sin brillar en el espacio backend JVM

Uno de los problemas fundamentales de Kotlin en el backend es su relativa dependencia de IntelliJ IDEA, lo cual no es un problema en desarrollo móvil, pero es un problema en desarrollo backend.

El desarrollador backend Java tradicionalmente:

  1. Trabaja en una institución financiera, startup consolidada o empresa de telecomunicaciones
  2. Soporta proyectos desde Java 6 hasta Java 11
  3. Pertenece a grupos ligeramente grandes de desarrolladores (+10 devs)
  4. Despliega sus aplicaciones en un applicaton server con soporte comercial -e.g. WebLogic, WebSphere, TomEE-.
  5. Utiliza algun IDE basado en NetBeans o Eclipse

Aunque es viable programar utilizando IntelliJ IDEA community en fatjars y microservicios, lo cierto es que se necesita IntelliJ IDEA completo para interactuar con application servers desde el IDE, lo cual limita el nivel de adopción que puede tener el lenguaje en entornos tradicionales.

Dificilmente un CTO va a decidir dar el salto de IDEs gratuitos y de calidad como NetBeans o Eclipse hacia IntelliJ donde cada copia arranca en aprox. $500. En esta linea, el soporte para Kotlin en NetBeans está muerto y el soporte en Eclipse no es el mejor.

4. JakartaEE renacerá o morirá

Luego del tumultoso traspaso de Java EE desde Oracle hasta la fundación Eclipse, se estan resolviendo finalmente las novelas alrededor del proceso, entre las más importantes:

  • La imposibilidad de utilizar el paquéte javax.*
  • La propiedad intelectual sobre la documentación
  • La propiedad intelectual sobre estandares como CDI
  • El nuevo proceso de certificación y TCK

Por lo que he leído en las listas, la tendencia en JakartaEE 9 sera remover APIs poco utilizadas en Java EE 8, pero el veredicto final si esto sera sostenible a largo plazo sera la comunidad.

Uno de los primeros pasos en la linea correcta fue el contar con implementaciónes compatibles con JakartaEE 8 lo que demuestra la solidez del proceso, pero 2020 sera crucial para la supervivencia de los estandares empresariales en Java. Creo que Eclipse ha hecho todo lo que está en su poder para involucrar fabricantes, pero sobre todo a la comunidad.

Como «lobo viejo» que cree en los estandares y la independencia de proveedores, espero que esto sea exitoso, a nivel personal lo que me ha mantenido en Java todo este tiempo no es el lenguaje, es el ecosistema y la independencia de proveedor.

5. Java 14 sera para muchos la primera beta de Java 17

Con cada nueva versión de Java, la mayoría de características nuevas suelen encajar en 3 grandes categorías:

  • Mejoras al lenguaje de programación
  • Mejoras a la JVM (entorno de ejecución)
  • Mejoras a las herramientas del Java Developer Kit

Por alguna razón las mejoras que suelen interesar a más desarrolladores siempre son las mejoras en el lenguaje y Java 14 sera un lanzamiento prometedor en esta categoría, el cual incluye algunas de las novedades más esperadas en el lenguaje:

¿Porqué la beta de Java 17?. De acuerdo al nuevo esquema de lanzamientos predecibles de Java, el siguiente LTS de Java es Java 17, donde la mayoría de personas se suben al vagón de la innovación.

6. Finalmente se estabilizara la gran batalla de las distros Java

Luego de que Oracle decidiera cambiar la licencia de su Java Virtual Machine, vimos el nacimiento de la gran batalla de las distros Java.

TL;DR: Java sigue siendo libre y gratis. Casi todas las distros se basan en código del proyecto OpenJDK.

Mi predicción es que algunas distros moriran por falta de interés o masa critica, pero seguramente las siguientes serán las sobrevivientes:

  1. AdoptOpenJDK: Fue la que pegó primero, presentó un website más bonito y es la preferida del sector hipster por no depender de un único proveedor.
  2. Oracle HotSpot: Porqué es obligatoria para cualquier cliente con productos Oracle
  3. SAP JVM: Porqué es obligatoria para cualquier cliente con productos de SAP
  4. OpenJDK de RedHat: Porqué es obligatoria para cualquier cliente con soporte comercial de Red Hat
  5. OpenJDK de tu distro Linux favorita: Si no usas Red Hat, probablemente usas una compilación propia de la distro que vivira mientras viva la distro. Son demasiados links para cada distro Linux «raiz».
  6. Azul Zing: Encontró su nicho en alianzas con proveedores importantes como Payara o Microsoft. Además de la experiencia de Azul Systems en la creación de JVMs.
  7. OpenJ9: Porqué es la JVM oficial de IBM.

No dudo en que alguien más decidirá sacar su propia distro de OpenJDK, pero como bien ha demostrado Linux, pueden existir 100 o más distros pelotudas pero todas al final derivan de 2 o 3 proyectos realmente importantes.

Eclipse MicroProfile para aplicações monolíticas

PT-BR Esses videos aqui foram o resultado da versão em português da palestra «Eclipse Microprofile for monolitic applications» apresentada em português no TDC Porto Alegre 2019. Os vídeos apresentam alguns use cases nos quais mesmo sendo deployments monolíticos as APIs do MicroProfile podem ser uteis.

ES: Estos videos son el resultado de una presentación en TDC Porto Alegre 2019, están todos en portugues pero no tengo blog en portugues para compartirlos :).

Algunas conclusiones aleatorias de la educación para programación con Java en Guatemala

Durante el meetup 2019.07 el grupo de usuarios Java de Guatemala tuvo a bien realizar una discusión con el tema enseñanza de Java en la academia.

Para esta reunión nos acompañó personal docente y académico de la Universidad de Costa Rica (sede pacifico) específicamente de la carrera de informática empresarial -i.e. desarrollo de software comercial-.

Diferente de muchas reuniones de GuateJUG, en esta ocasión logramos juntar un grupo heterogéneo de actores en el sector educativo, incluyendo profesores de enseñanza media, Universidad Mariano Galvez, Universidad Rafael Landivar, Oracle Workforce Development, Oracle University y personas de la industria bajo la misma pregunta.

¿Como y porqué es fácil/dificil enseñar programación con Java a nivel universitario?

En linea con el debate, comparto mis notas de la discusión:

  • Todos coinciden que las clases a nivel universitario en Centro América aun se dan con Java 6/7 porqué ningún programa de estudios incluye programación funcional. Esto es especialmente problemático en programación asíncrona, sistemas escalables y micro servicios, la industria NECESITA programadores con capacidades funcionales y no los encuentra.
  • Un problema aun vigente en Guatemala es que durante los años 90 la industria se desarrolló en base a tecnologías propietarias. De los asistentes alguien que se había formado en los años 90s dio su «testimonio» de como eso limitó su carrera profesional.
  • Todos los asistentes coinciden que el peor de los factores para desistir de aprender Java fue/es un mal profesor que no tiene buenos fundamentos de POO, algunos de los síntomas comunes:
    • No sabe utilizar interfaces
    • Codifica todo con métodos estáticos
  • El mejor IDE para aprender fundamentos de POO es BlueJ
  • El mejor IDE profesional para principiantes en Java es NetBeans
  • De todos los asistentes por lo menos el 30% aprendió a programar utilizando Java como primer lenguaje, el resto recibió formación previa en Pascal, C y Scratch. Al parecer es el patrón común en Centro América.
  • De las personas que aprendieron con Java como primer lenguaje, todos coincidieron que eso les abrió las puertas a dominar cualquier otro lenguaje ya que es el lenguaje más fácil para aprender programación orientada a objetos.
  • Todos los asistentes coincidieron en que el proceso de enseñanza de programación es el siguiente y es malo por un motivo:
    • Se aprende algoritmos básicos (precisos, finitos y determinados)
    • Se elaboran ejemplos en pseudocodigo de estos algoritmos
    • Se elabora un programa de computadora a partir del pseudocódigo con sentencias 0- secuenciales, 1- condicionales, 2- repetitivas, 3- invocación
  • El motivo por el cual es «malo» es porque traducir pseudocódigo hacia un lenguaje POO (Java/C#) es un proceso antinatural ya que el pseudocódigo es en esencia programación estructurada
  • Las opciones planteadas al problema anterior son:
    • Live coding en clase
    • Java REPL
    • Uso de otro lenguaje como Groovy que soporta ambos paradigmas y puede ser un buen paso intermedio hacia Java/C#
  • Uno de los principales problemas de empatar con las necesidades de la industria, es que la industria solicita dominio de frameworks. En su afan de entregar gente capaz a la industria la academia introduce estos frameworks sin mucho éxito o metodología.
  • Un problema poco visible es que los frameworks modernos y sobre todo su documentación presuponen que el lector sabe:
    • Meta-programación (anotaciones)
    • Patrones de diseño
    • Domain Driven Development
  • El JavaScript moderno es un desmadre, ES6 tuvo avances pero para alguien que ya sabe Java . . . es un desmadre
  • Aprender Kotlin como primer lenguaje podría ser un suicidio . . . pero es fácil para alguien que ya sabe Java

Espero que estas conclusiones le sirvan a alguien con el poder adecuado para cambiar la educación en el país.

Gentoo Linux Unstable + Common Desktop Environment (CDE)

Es un sistema Unix, lo conozco

He cruzado la ultima frontera hipster . . .

Luego de revivir una de mis PCs desechables con Sabayon Linux y apariencia CDE, me pregunte a mi mismo

¿Que tal dificil sera tener el CDE real?

Yo mientras migraba un proyecto de Parcel a Webpack

Aunque tengo bastante experiencia con Linux (casi 15 años si lo pienso bien), durante mi carrera profesional he tenido muy pocas oportunidades de utilizar escritorios Unix reales. Muy a lo lejos recuerdo haber utilizado una Sun Ultra con Solaris 8 en una consultoria Java 1.4 y una vez utilicé una estación de trabajo con HP-UX cuando era niño. En su momento con la estación HP-UX quedé fascinado y recuerdo a lo lejos que alguien me mencionó que era el sistema que utilizaban en Jurassic Park.

CDE en su momento fue EL ESCRITORIO para Unix y OpenVMS. Nacido como una iniciativa de HP, IBM, Sun y USL (AT&T), teniendo como objetivo en común estandarizar el escritorio utilizado en las diferentes versiones comerciales de UNIX.

Hoy en día prácticamente solo AIX y Solaris continúan el legado UNIX que fue totalmente aplastado por Linux, pero siempre estuve maravillado por CDE.

¿Que tal dificil es instalar CDE?

Originalmente CDE era posible de utilizar en algunas variantes de Unix y Linux bajo una licencia carisima. Luego llegaron GNOME, KDE y otros para cambiar el panorama con lo que CDE quedó en el olvido, aunque aun como propiedad intelectual de The Open Group, el cual a solicitud de una petición online decidió liberar en 2012.

Comparado a los entornos de hoy en día, compilar CDE es una tarea relativamente rápida, especialmente si se usan distribuciones basadas en compilación como Gentoo Linux.

La wiki establece varios pasos y dependencias requeridas para la compilación, aunque no está oficialmente soportado, utilizando como base las dependencias de OpenSUSE no tuve inconvenientes para compilarlo en Gentoo, el resultado final es hermoso.

Cuando estaba en la universidad siempre me pregunté porque Java swing trae el tema Motif . . . y hasta hace pocos años supe que Motif, era el toolkit y widgets utilizado por CDE, por lo que NetBeans no se ve fuera de lugar en su nuevo escritorio 🙂.

Microservicios con MicroProfile y Kotlin

Este es un Raw recording de la presentación dictada en Google I/O Extended Guatemala 2019, donde exploramos el uso y motivaciones de utilizar Kotlin en conjunto con MicroProfile, asi como algunos comentarios generales de construcciones utiles de Kotlin para lograr código conciso.


El enfoque de la camara no estaba bien, pero dejando eso a un lado la demo con Docker funcionó sin inconvenientes :).

Los slides estan disponibles en speakerdeck: https://speakerdeck.com/tuxtor/microservicios-con-kotlin-y-microprofile

Probando /e/, la distro Android del creador de Mandrake Linux

El Linux que instalaron en mi colegio porque el director no quería pagar licencias

Como parte de mi política trimestral de actualizar todos mis dispositivos me vi en la necesidad de actualizar mi teléfono «para ejercicio». En Guatemala (mi ciudad actual) es bastante común que las personas tengan dos teléfonos por las tazas criminales, uno para robos y uno real; o como en mi caso, uno para llevar ejercitarme en la calle y uno real.

Mi teléfono para ejercicios es un Nexus 5 que quedó hace tiempo sin soporte oficial -i.e. sin actualizaciones de seguridad-, pero es una bestia hackeable como telefono Android. Asi, ha sobrevivido al paso del tiempo utilizando ROMs comunitarias como CyanogenMod, Replicant, AOKP y LineageOS. Dada la reciente batalla entre Huawei y Google quise aprovechar la actualización para preguntarme:

¿Que tan dificil es hoy en día utilizar un teléfono con Android sin soporte de Google?

Yo merengues

Y así me tope con el proyecto /e/, liderado por Gaël Duval, conocido principalmente por ser uno de los creadores de Mandrake Linux.

La idea de /e/ es crear un ecosistema de smartphone basado en Android bajo 3 principios:

  • Ser libre de Google -i.e. No Google Location, Play, Gmail, Maps y Users Tracking-
  • Respetar la privacidad del usuario
  • Ser atractivo incluso para padres y madres

Esto ultimo, es lo que lo diferencia de Replicant cuyo principal objetivo es ser libre como Frozen.

La instalación es bastante promedio para teléfonos como el Nexus 5 que son fáciles de liberar, basta con descargar la ROM, iniciar algún tipo de recovery como TWRP y hacer flash del zip file descargado, con esto oficialmente el teléfono ejecuta /e/. Se espera que en un futuro no muy lejano sea posible adquirir teléfonos que traigan /e/ de serie.


Cada rajadura es una aventura

Al inicio /e/ presenta la opción de acceder a servicios avanzados mediante una cuenta de /e/, aun no estoy muy seguro del alcance de esta cuenta por lo cual me la he saltado simplemente y el telefono es usable. Luego, se presenta una interfaz bastante copia de iPhone/Samsung/Huawei

La propuesta de valor de /e/ es que la mayoria de apps «vitales» son reemplazadas en el teléfono por forks/nuevas aplicaciones Open Source (en su mayoría), sin embargo su «App Store» brinda acceso a aplicaciones populares tanto de código abierto como propietario.

La interfaz no es la octava maravilla del mundo, pero si es más amigable que F-Droid. Durante mis pruebas pude instalar varias aplicaciones propietarias pero vitales para mi, como:

  • Dropbox
  • Keepass2Android
  • Runkeeper
  • Facebook

Al instalar aplicaciones es posible ver los resultados de privacidad de cada app de acuerdo a Exodus Privacy en un conveniente candado bajo el boton install.

Sin embargo el proyecto aun está en sus inicios, lo cual se nota al abrir aplicaciones «vitales» como Mail

Hasta el momento es una de las distros Android más pragmáticas que he utilizado, sinceramente espero que este u otro proyecto logre masa critica, es demasiado peligroso que la tecnología dependa arbitrariamente de las decisiones de un solo gobierno.

Deshabilitar unidades de systemd en GRUB (o como reviví una PC de 2010 con Sabayon Linux)

Pingüinos Gentoo, los más rapidos de la tierra

Actualmente mi computadora principal es una Macbook Pro 15 luego del fiasco Wayland vs Nvidia y la incapacidad de hacer scaling HiDPI con resoluciones mixtas -i.e. no puedo utilizar pantallas HiDPI y proyectores a la vez-.

Sin embargo, tradicionalmente suelo utilizar una computadora de 2010 para mis labores como docente universitario, específicamente una Dell Mini 1012 la cual se «arrastraba» con Linux Mint Rosa(2016) que llegó al final del camino durante abril de 2019, obligándome a actualizarla con un dist-upgrade y obteniendo como resultado una computadora incapaz de bootear.

Dado que nunca he sido fanático de distribuciones basadas en Debian, decidí aprovechar este fracaso para probar algunas distribuciones y revivir nuevamente al muerto, obteniendo una y otra vez el mismo resultado con todos los pendrive que preparaba, incluyendo:

  • Sabayon
  • Fedora Workstation
  • CentOS 7
  • Manjaro
  • Calculate Linux

Aunque inicialmente daba por muerto el computador, mi viejo corazón de *NIX hacker me decía que no todo estaba perdido; luego, probé instalar una versión muy vieja de Gentoo Linux (Gentoo 2012 «End of World») y fui capaz de iniciar, por lo que el error era probablemente una regresión en versiones actuales del kernel.

Luego de un par de horas en el bugzilla de kernel.org descubrí que existe un error reportado para ciertos modelos Dell desde el año 2015 y que ha sido también reportado en Arch Linux y Red Hat, el cual solo se activa bajo una serie de eventos desafortunados:

  1. La computadora debe ser una Dell antigua sin teclado retroiluminado
  2. systemd intenta restaurar el nivel de iluminación previo (o nivel por defecto en instaladores)
  3. El kernel se congela por una interrupción y una versión especifica de BIOS, básicamente intenta restaurar el nivel de iluminación . . . en un teclado sin iluminación

Mi vieja versión de Linux Mint Rosa no presentaba este problema ya que fue uno de los ultimos Linux Mint en resistir ante systemd. Sin embargo y como sugieren varios workarrounds, el camino más lógico es enmascarar el servicio demoníaco con un simple:

systemctl mask systemd-backlight@leds:dell::kbd_backlight.service

Lo que en mi caso era imposible ya que había arruinado la instalación antigua de Linux Mint y los instaladores de nuevas distros eran incapaces de arrancar.

Afortunadamente una de las capacidades de systemd es recibir parámetros desde el Kernel mediante kernel-command-line. Asi, es posible alterar ligeramente los instaladores ya que la mayoría (si no todos) los instaladores de Linux siempre tienen como primer pantalla un Grub glorificado, por lo que basta con agregar el siguiente parametro a la linea de arranque:

systemd.mask=systemd-backlight@leds:dell::kbd_backlight.service

Como resultado final decidí quedarme con Sabayon Linux, la variante binaria más popular de Gentoo (mi distro de todos los tiempos) luego de Chrome OS, sin embargo para poder iniciar el instalador en computadoras tan viejas es necesario hacer un pequeño hack en el instalador Calamares para que acepte menos de 1GB de memoria RAM.

Para preservar el sentimiento a vejestorio, decidí utilizar Fluxbox con apariencia de HP-UX (Motif/CDE), tal vez en algún momento intente compilar OpenCDE.


Hands on Lab: Jakarta EE 8, MicroProfile y Oracle Cloud

Recientemente tuve la oportunidad de dictar dos conferencias en Es-Conference, uno de los mayores eventos JVM en México (y uno de mis favoritos en el circuito JVM en general).

Una de ellas fue un Live Coding/Hands on lab acerca de Java EE 8 y Eclipse MicroProfile. En esta conferencia se cubren los siguientes aspectos con un Hands on Lab simple:

  • Creación de un proyecto con Jakarta EE 8
  • Implementación de MicroProfile en un proyecto Jakarta EE
  • Implementación de servicios REST mediante JAX-RS
  • Externalización de la configuración via MicroProfile Config
  • Creación de clientes REST Typesafe con MicroProfile Rest Client
  • Creación de metricas con MicroProfile Metrics
  • Tolerancia a fallas con MicroProfile Fault Tolerance
  • Ejecución de microservicios con Payara Micro, Docker y Docker Compose/Swarm
  • Despliegue de aplicaciones docker en Oracle Container Registry y Oracle Cloud

Los slides utilizados como referencia estan disponibles en SlideShare

Y el código (bastante simple en realidad) se encuentra disponible en mi GitHub: https://github.com/tuxtor/MP-Workshop

Introducción a pruebas con Java EE 8, Arquillian y Payara 5

@Inject all the things

Continuando con el post anterior en Nabenik decidimos compartir nuestra capacitación interna de introducción a pruebas con Java EE 8, Arquillian y Payara 5.

Como de costumbre en este tipo de capacitaciones, iniciamos con la creación de un CRUD simple con Java EE 8 vanilla.

Posteriormente preparamos el proyecto para soportar Arquillian, JUnit y Payara 5.

Posteriormente escribimos nuestra prueba con ShrinkWrap.

Y finalmente lo que toda Latinoamerica unida esperaba, la creación de un test sobre un EJB.

Introducción a pruebas con JUnit y Mockito

Cuando tu mvn verify da 0 errores

Uno de los puntos más importantes y a la vez más descuidados en la educación superior en Guatemala en TI (al menos desde mi punto de vista), es la correcta implementación de pruebas de software.

Como parte de nuestras capacitaciones internas, en Nabenik decidimos compartir nuestra capacitación de introducción a JUnit y Mockito. La capacitación está enfocada a ser útil para cualquier framework de integración basado en JUnit, incluyendo Arquillian y Spring Testing, por lo que se utiliza JUnit 4, pero los conceptos son útiles para JUnit 5 por igual.

Comenzamos con la parte teórica y las motivaciones de las pruebas de software automáticas:

Posteriormente exploramos el uso de JUnit con IntelliJ IDEA (pero aplicable a cualquier IDE).

Luego controlamos las pruebas utilizando las anotaciones Before, BeforeClass, After y AfterClass

Y finalizamos con creación de Mocks utilizando Mockito