9 errores que hay que evitar al programar en Java
¿Qué errores deben evitarse al programar en Java? En el siguiente artículo responderemos a esta pregunta.
Hay un medio de oro para manejar muchos entornos para un gran número en una sola máquina? ¡Nuestro experto en Java Bartłomiej conoce la respuesta!
Echemos un vistazo a un entorno de trabajo típico en un empresa de software. Tiene varios clientes con entornos diferentes. Algunos prefieren MySQL, otros Postgres. Una versión de su aplicación necesita Java 11, y otra Java 17. Frontend necesita npm 12 o 16 porque utiliza diferentes versiones de angular. Finalmente, tienes ese array tridimensional que contiene combinaciones de todas tus DBs, backend, y versiones frontend. Suena mal, pero un día tu jefe dice...
La situación descrita anteriormente no es algo infrecuente. Migraciones entre versiones de lenguajes o frameworks, actualizaciones de bases de datos o simplemente diferentes requerimientos provenientes de los clientes pueden poner patas arriba todas las configuraciones. Deberíamos tener una solución que nos ayude a gestionar esos cambios, una que se ajuste a unos supuestos y/o requisitos y/o objetivos:
En este artículo, me centraré en tres áreas. La primera son las herramientas para Java y JVM. La segunda son las herramientas de propósito general. La tercera es cómo utilizar docker para lograr nuestros objetivos.
Cuando eres un Desarrollador Java o, de forma más general, trabaja con Tecnologías JVMpuede utilizar ¡SDKMAN!. Se trata de una herramienta muy agradable y fácil de usar que admite muchas bibliotecas, marcos de trabajo y lenguajes.
El proceso de instalación de ¡SDKMAN! Es bastante sencillo. Tienes que correr:
curl -s "https://get.sdkman.io" | bash
y luego
source "$HOME/.sdkman/bin/sdkman-init.sh"
Ahora puedes gestionar tu Java, Scala y Maven versiones.
En este ejemplo, instalaremos y actualizaremos la versión de unas pocas herramientas. Esto es sólo un pequeño subconjunto de las herramientas disponibles.
Supongamos que su nuevo proyecto utiliza Java 17. Usted no tiene ningún Java instalada. Quieres instalarla y, además, añadir una herramienta Maven Daemon para hacer las construcciones más rápidas. Por lo tanto, es necesario instalar Maven, también. Para ello, es necesario ejecutar tres comandos simples:
$ sdk install java 17-open
$ sdk install maven 3.8.4
$ sdk install mvnd 0.7.1
Al final de la instalación de cada herramienta, se le preguntará si desea convertirla en predeterminada:
¿Desea que Java 17-open se establezca como predeterminado? (S/n):
Esto es importante cuando se instala una nueva versión de una librería o de un lenguaje, ya que SDKMAN! establecerá esa versión por defecto como global para todos los terminales del usuario actual.
De vez en cuando, SDKMAN! necesita actualizar los índices. Durante este proceso, es posible que reciba un mensaje indicándole que hay nuevas versiones de las herramientas que utiliza. Podemos comprobar qué versiones están disponibles escribiendo sdk ls
. Para sdk ls maven
:
Versiones disponibles de Maven
================================================================================
3.8.6 3.3.3
3.8.5 3.3.1
3.8.4 3.2.5
3.8.3 3.2.3
3.8.2 3.2.2
3.8.1 3.2.1
3.6.3 3.1.1
3.6.2 3.1.0
3.6.1 3.0.5
3.6.0 3.0.4
3.5.4
3.5.3
3.5.2
3.5.0
3.3.9
================================================================================
versión local
actualmente en uso
================================================================================
Como vemos arriba, Maven tiene una versión más nueva que la que usamos. Lo mismo ocurre con mvnd
(0.8.2) y Java (19-open). Vamos a actualizarlo todo. Para ello, sólo tenemos que llamar al comando install pero en esta ocasión, no utilizamos un especificador de versión:
$ sdk install maven
$ sdk install mvnd
$ sdk install java
Pero algo malo ocurrió. Maven
y mvnd
tienen versiones correctas, pero Java tiene versión 17.0.5-tem
. Esto se debe a que "la versión más reciente" de la herramienta está controlada por su proveedor y no por SDKMAN! ¿Quién es este proveedor? Un vendedor en SDKMAN! es alguien que puede publicar una versión. Sin embargo, digamos que finalmente instalamos 19-abierto
y lo hicimos por defecto, pero por alguna razón, necesitamos usar 17-abierto
.
Podemos configurar un por defecto
versión de una herramienta que es global para todos los proyectos y terminales. Pero cuando necesitamos una versión específica, tenemos dos formas de hacerlo. La primera es utilizar el sdk use
cada vez que queramos utilizar una versión específica de una herramienta en el terminal actual. La segunda es preparar una lista de versiones en un .sdkmanrc
que se almacena con el proyecto.
Mientras que la primera opción es de uso individual, la segunda está pensada para trabajar en equipo y compartir configuraciones entre equipo miembros.
SDKMAN! es muy fácil de usar y cuenta con una rica biblioteca de herramientas, marcos de trabajo y lenguajes compatibles. Funciona en Linux, MacOS y Windows. Por otro lado, esta herramienta está centrada en JVM y requiere la aceptación del autor para ser proveedor. Además, la mecánica de .sdkmanrc
es muy pobre y podría ralentizar considerablemente el proceso de cambio de directorios.
Si necesita utilizar muchos idiomas y herramientas, debería echar un vistazo a asdf. Esta herramienta se centra en herramientas de "alto nivel". Mientras que en SDKMAN! puedes encontrar muchas herramientas específicas para Java, como Bpipe o Znai, asdf ofrece muchas más herramientas pero no tan específicas. Por supuesto, algunas de esas herramientas se solapan, por ejemplo Java, Tomcat o mvnd están disponibles en ambas.
Cuando desee utilizar asdf
necesita tener git
y rizo
instalado. Después de eso, sólo:
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.10.2
y añade estas líneas en ~/.bashrc
file:
. $HOME/.asdf/asdf.sh
. $HOME/.asdf/completions/asdf.bash
Ahora puedes instalar plugins y herramientas en tus versiones favoritas.
A diferencia de SDKMAN!, asdf
utiliza plugins para gestionar las herramientas. Por lo tanto, antes de poder instalar una herramienta, es necesario instalar un plugin. Volvamos a nuestro proyecto de ejemplo e intentemos configurar el entorno utilizando asadfsdf
.
En primer lugar, tenemos que instalar plugins:
asdf plugin add java
asdf plugin add maven
asdf plugin add mvnd
Entonces podremos instalar nuestras herramientas:
asdf install java openjdk-17
asdf install maven 3.8.4
asdf install mvnd 0.7.1
Y una vez más, a diferencia de SDKMAN!, asdf
no cambia nada en nuestro entorno. Cuando tratamos de usar java, obtenemos un mensaje de error como:
No hay versión para el comando Java
Considere añadir una de las siguientes versiones en su archivo de configuración en ~/.tool-versions
java openjdk-17
Necesitamos crear el archivo .versiones-herramienta
en el directorio de inicio para gestionar las versiones por defecto.
Actualización de versiones de software con asdf
es bastante simple. Simplemente instalamos una nueva versión. Como este proceso no afecta al entorno, podríamos hacerlo en cualquier momento y en cualquier lugar del sistema de archivos. Cuando queremos utilizar una versión específica de algún software, necesitamos crear en el directorio del proyecto un archivo .versiones-herramienta
que puedan compartir los miembros del equipo. Recuerde que debe garantizar que todos los miembros del equipo tienen asdf
y plugins instalados. La lista de plugins que puedes encontrar aquí.
asdf
no sólo soporta lenguajes de programación, frameworks y herramientas como vim o kubernetess. También soporta bases de datos. En tal caso, podríamos instalar varias versiones de, por ejemplo, Postgres, pero sólo podría ejecutarse una instancia. Esto se debe a que asdf
ejecuta comandos directamente en tu sistema operativo sin ninguna capa de separación. Esto conlleva problemas como "puerto ya en uso" y conflictos de recursos.
asdf
es una herramienta muy buena si quieres trabajar en un entorno políglota. Soporta muchas herramientas, lenguajes y frameworks. Su arquitectura basada en plugins hace que sea muy fácil ampliarla. Sin embargo, algunas de las herramientas que tiene en la biblioteca necesitan un trabajo adicional durante la instalación para proporcionar todas las dependencias necesarias. asdf
no funciona en Windows, ni siquiera en WSL.
Cuando hablo del conflicto portuario más arriba, muchos de ustedes conocen la solución.
Docker podría ayudarnos en algunos casos. Lo menciono por obligación, porque esta herramienta es tan grande y compleja que no podemos hablar de ella en un solo artículo.
Junto con Docker, deberíamos utilizar un docker-compose que nos da la posibilidad de coordinar entornos multicontenedor.
Docker nos ayuda a gestionar herramientas que necesitan algunos recursos específicos, como puertos o archivos. Separa instancias en contenedores y nos da un control total sobre ellas. Sin embargo, Docker es una herramienta que introduce mucha complejidad en nuestro entorno de trabajo y puede ser problemática en algunos casos. Uno de esos casos de uso de Docker en una prueba se describe en uno de nuestros anteriores artículo.
Sé que no he descrito todas las herramientas que se pueden utilizar para gestionar las versiones de las herramientas. Hay muchas más, como jEnv que podría sustituir a SDKMAN,
o NVM que podemos utilizar para gestionar npm o RVM para Ruby. Me he centrado en herramientas que he "probado en el campo de batalla" y que puedo recomendar a cualquiera.