Por qué Java sigue siendo popular

Este es un buen momento para publicar esto, justo en el lanzamiento de Java 19. Sí, otra publicación de "mi idioma es mejor". No, no quería escribirlo. Pero a veces la mala proyección de la gente saca lo mejor de mí. En este caso, la publicación comenzó como un comentario y terminé decidiendo convertirlo en una publicación. Esto se reforzó con esta publicación que en su mayoría se queja de Quarkus (algo injustamente si se me permite agregar).

El primer artículo es en su mayoría una tontería y un clickbait desactualizado. Te lo resumiré en las siguientes afirmaciones:

• captadores/establecedores
• Falta la sobrecarga del operador específicamente para [] en colecciones y + en cualquier cosa
• Excepciones comprobadas
• Gestión de dependencias

El segundo artículo tiene quejas que están más relacionadas con Jakarta EE y la estética general del programador en JVM. Específicamente el uso de anotaciones para validaciones y reclamos similares. Este es un artículo mucho mejor informado, pero tiene un par de fallas que abordaré cerca del final.

Getters y Setters

Getters y setters no son necesarios para Java moderno. Tenemos registros desde Java 14 y Lombok sigue siendo bueno a pesar de algunas afirmaciones en sentido contrario. El único punto en el que necesitaríamos getter/setters es en configuraciones muy específicas (p. ej., JPA) donde, de nuevo, Lombok resuelve el problema a la perfección.

El artículo se convierte en una diatriba sobre la falta de características de azúcar sintáctica en Java. Esto es intencional. Puede consultar Kotlin si está interesado en los últimos matices de sintaxis. Java se trata de "lento y constante". Eso es algo bueno y la razón principal detrás de la longevidad de Java.

Sintaxis Sugar y sobrecarga de operadores

Java moderno incluye patrones en switch, var, cadenas multilínea y mucho más. Algunas características próximas incluyen plantillas de cadena. La compatibilidad con la plantilla de cadenas lleva un tiempo porque Java quiere "hacerlo bien". Hay algo de soporte para eso en el nivel de API (y lo ha sido por un tiempo). Esto no es eficaz. El objetivo de las plantillas de cadenas es crear una sintaxis anulable radical que permita cosas como:

 ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}";

Actualización: desde la publicación de esta publicación, los desarrolladores asumieron erróneamente que el código anterior es una vulnerabilidad de inyección SQL. no lo es Esto parece un reemplazo de cadena, pero es un código que usa esa sintaxis para generar una llamada SQL parametrizada.

¡Observe que el name es una variable que el compilador verificará y obtendrá del alcance dinámicamente!

El desarrollador puede implementar DB de manera personalizada y no es necesario que esté "incorporado" para que pueda construir plantillas complejas en el lugar.

Pero hablemos del Java que tenemos hoy, no del que viene en 6 meses. Usar append no ha sido la recomendación para String durante una década o más. Utilice + , que es el más eficaz y más fácil de leer. Acerca de las colecciones, la diferencia entre get() y [] es literalmente cuatro caracteres. Esos personajes importan mucho. Podemos anular esto fácilmente. También podemos entender las diferencias semánticas. Las matrices de Java son MUY rápidas, en muchos casos, la velocidad nativa es rápida. Las colecciones no pueden ser tan rápidas, el hecho de que podamos ver esto aquí al instante es muy valioso.

El hecho de que los operadores no puedan estar sobrecargados es un GRAN beneficio. Si veo a + b , sé que esto es una cadena o un número, no un método oculto. Esa es una de las mayores fortalezas de Java y una de las razones por las que ha sido popular durante casi 30 años, mientras que otros lenguajes se dejan de lado. La sintaxis de Java está diseñada para leer a escala. Cuando tienes un proyecto con 1M de líneas de código o incluso 100k, los problemas cambian. En este punto, es difícil descubrir que el programador X en el módulo Y anuló a un operador incorrectamente cuando está depurando un problema. La sintaxis debe ser simple en ese momento y cualquier costo menor que haya ahorrado inicialmente se pagará con un interés de 10x. La definición de cambios simples como código se vuelve más compleja y envejece. Agregue a eso el poder de las herramientas para analizar código estricto y simple a gran escala y esto se convierte en un beneficio aún mayor.

Excepciones marcadas

Las excepciones marcadas son opcionales. Pero son una de las MEJORES características de Java. Tanto código falla inesperadamente. Cuando construyes cosas como pasatiempo, podría estar bien. Cuando desea crear una aplicación profesional, debe manejar todos los errores. Las excepciones marcadas te ayudan a evitar esas tonterías. La gente odia las excepciones comprobadas debido a la pereza. Java te protege contra ti mismo.

No debería haber ningún caso en el que haga una conexión de red, una conexión de base de datos, abra un archivo, etc. y no necesite manejar el error potencial. Puedo patearlo, pero luego las excepciones verificadas me obligan a seguir pateándolo en alguna parte. Es una característica asombrosa.

dependencias

Tengo muchos problemas con Maven y Gradle. Pero cuando lo comparas con casi cualquier otro sistema de dependencia con algo de millaje, lo están haciendo muy bien. Tienen problemas, pero no puedes compararlos con algo joven como la carga que, en comparación, casi no tiene paquetes. Maven central es ENORME con 27 terabytes de archivos jar y 496 mil millones de solicitudes. Funciona perfectamente y casi no tiene tiempo de inactividad.

Otras herramientas como NPM demuestran perfectamente las fortalezas de maven. Si las dependencias en maven son un problema, entonces NPM tiene 100 veces el problema y no tiene supervisión. A medida que estas cosas crecen hay complejidades. Especialmente con múltiples versiones de maven en el mercado. Sin embargo, una de las cosas que Maven y Gradle tienen a su favor son las herramientas. En muchos casos, los IDE ayudan a resolver problemas y encuentran la solución de inmediato.

Problemas culturales en Java

El segundo artículo es más interesante y hasta cierto punto estoy de acuerdo. Los desarrolladores de Java tienden a convertir cada problema en un problema más complicado. En algunos casos, esto es necesario, Java es el gorila de 800 libras de las plataformas de programación y sus soluciones a menudo tienen un exceso de ingeniería. Esto tiende a ser mejor que con poca potencia, pero tiene un precio.

Por qué anotación para validación

El artículo mencionó un ejemplo interesante que parece "lo correcto" para el observador casual pero es problemático.

 @NotNull @Email String noReplyEmailAddress

El autor afirma que esto es malo y que uno debería implementar una escritura personalizada, por ejemplo:

 public record EmailAddress(String value) { public EmailAddress { // We could've used an Either data type, ofc; Objects.requireNonNull(value); // regexp could be better if (!value.matches("^[^@\\s]+@\\S+$")) throw new IllegalArgumentException( String.format("'%s' is not a valid email address", value)); } }

Esto es totalmente posible en Java, ya que el código anterior es un código Java válido. Pero tiene varios problemas, por eso tenemos la validación de beans.

• Esto no se puede optimizar: el marco puede mover la validación de Bean hacia arriba en la cadena de validación. Incluso se puede validar en el código del lado del cliente sin problemas, ya que es una API declarativa. Aquí necesitamos ejecutar el constructor para realizar la validación.
• Las anotaciones declarativas se pueden mover hacia abajo en la cadena para aplicar las restricciones de la base de datos sin problemas, etc.
• Podemos aplicar varias anotaciones a la vez
• La sintaxis es más concisa.

Como resultado, las anotaciones pueden parecer raras y no obligan a escribir. Eso es cierto. Pero aumentan el rendimiento y la potencia. Hay mucho pensamiento y sentido común detrás de su uso. Entiendo el punto de los autores, tampoco soy un gran fanático de IoC, pero en este caso específico es incorrecto.

Finalmente

Este artículo pasó demasiado tiempo a la defensiva. Es hora de cambiar de marcha. Java existe desde hace casi 30 años y sigue siendo en su mayoría compatible con Java 1.0. ¡Eso es fantástico e inigualable!

Uno de los poderes de su enfoque conservador es que puede hacer increíbles optimizaciones "bajo el capó" sin que ninguno de ustedes se dé cuenta de lo que sucedió. Java 9 reemplazó por completo la forma en que las cadenas se representaban en la memoria sin problemas y redujo significativamente el uso de RAM. De manera similar, Loom aumentará el rendimiento de las aplicaciones sincrónicas de Java. Valhalla mejorará aún más el rendimiento de la colección y unificará la división Objeto/Primitivo. Panamá finalmente nos librará de JNI y hará que el proceso de integración con código nativo sea mucho más agradable.

Lo bueno es que la JVM es una gran carpa. Si no eres fanático de Java, Kotlin o Scala pueden ser de tu agrado. El beneficio de JVM se aplica universalmente y la mayoría de las características que mencioné aquí beneficiarán a todo nuestro ecosistema conjunto.