Miro con nostalgia mis tiempos mozos donde actualicé de Java 4 a Java 5 y la emoción que significaba ese tipo de actualizaciones. Ahora, ya abuelo en esto, mis emociones no son las mismas y ya no corro a poner la nueva versión de Java para disfrutar de esas promesas que se hemos leído estos meses atrás y más cuando no estamos ante una versión LTS, de esas que nos encanta poner en producción.
Igualmente, tenemos cosas nuevas ¿el qué? Sigan leyendo.
(más…)Interesante artículo escrito recientemente por Enrique Dans sobre vibe coding que merece la pena leer.
La discusión sobre el vibe coding ha alcanzado un punto interesante cuando deja de ser una crítica externa y empieza a formularse desde dentro del propio ecosistema que lo impulsa. Que el CEO de una de las herramientas más avanzadas de programación asistida por inteligencia artificial advierta de que estamos construyendo software sobre cimientos frágiles no es una anécdota ni un ejercicio de falsa modestia: es una señal de alerta que conviene tomarse muy en serio. No porque la inteligencia artificial no funcione, sino porque funciona lo suficientemente bien como para inducir una peligrosa complacencia.
Continuar en el blog de Enrique Dans.
La nueva versión de Java realmente no rompe nada no rompe nada (bueno, rompe a los que aún viven en 32 bits, ¿hola? ¿Hay alguien ahí?), pero pule bastante cosillas, veamos algunas cuantas.
Constructores más flexibles
Parece mentira, pero por fin se pueden hacer cosas antes de llamar a super() o this(). Ideal para validar argumentos o preparar datos.
// Antes: obligado a llamar primero a super
class Persona {
Persona(String nombre) { }
}
class Empleado extends Persona {
Empleado(String nombre) {
super(nombre); // obligatorio aquí
// Validar o transformar después
}
}// Ahora en Java 25
class Empleado extends Persona {
Empleado(String nombre) {
if (nombre == null) nombre = "Desconocido"; // ya puedo hacerlo antes
super(nombre);
}
}“La experiencia es ese maravilloso don que te llega justo después de haber metido la pata.” — Alguien que programó sin tests
Dicen que con el tiempo uno se vuelve mejor programador. Que la experiencia ayuda a evitar los errores de principiante. Y es verdad… en parte. Porque hay ciertos fallos que, por algún motivo misterioso, siguen apareciendo incluso entre desarrolladores con años de práctica en Java.
No hablamos de patrones complicados ni de problemas de concurrencia en microservicios. Hablamos de esos errores básicos, casi entrañables, que uno esperaría dejar atrás… pero no. Aquí va un repaso a 10 meteduras de pata que se siguen viendo —en proyectos reales, en producción, en 2025— por parte de programadores veteranos (ninguno de los cuales eres tú, claro).
(más…)Java 24 llegó en marzo 2025 y, como suele pasar últimamente, no viene con fuegos artificiales… pero sí con varias mejoras que te pueden hacer la vida un poco más llevadera. Nada de revoluciones ni promesas vacías. Solo cambios sensatos que huelen a “por fin”.
Aquí te dejo un resumen directo y sin lios, para que no tengas que leerte mil líneas de JEPs antes de tu siguiente café.
(más…)Aquí comienzo una serie de pequeños artículos para aprender a responder a preguntas típicas de una entrevista técnica, por un lado aprenderás a desenvolverte mejor y a la vez obtendrás conceptos interesantes que te pueden ser útiles en tu día a día, empezamos por un clásico de los clásicos, los dos métodos que puedes encontrar por defecto en toda clase que extienda de Object en Java, o sea, todas.
equals()
El método equals() de la clase Object se utiliza para comprobar si el objeto actual es igual o no al objeto que se pasa. Por defecto, comprueba la dirección de memoria del objeto de las instancias. Si ambos objetos tienen la misma dirección de memoria, entonces son iguales.
hashCode()
El hashCode(), de la clase Object, se utiliza para identificar un objeto de forma única. De forma predeterminada, devuelve la dirección de memoria del objeto en un formato de número entero.
La ventaja de utilizar juntos equals() y hashCode()
Para las clases Integer, Float, String, etc, no tienes que preocuparte por ellas. Pero para tus propias clases, es posible que desee sobrescribir estos métodos, siempre para casos especiales y no todo siempre.
Por ejemplo, si deseas usarlo como una clave en un Map o si no quieres tener objetos duplicados y esa duplicación está basada en algunos campos de identificación de la clase.
Al sobrescribirlo, nos aseguramos que equals() se base en hashCode() y hashCode() se base en un valor único. Entonces, si obj1.equals(obj2) es true, entonces obj1.hashCode() == obj2.hashCode() deberá ser true. Si no, pueden comportarse de formas muy extrañas.
Ejemplo:
Supongamos que tengo una identificación int (int id) en mi clase que debe ser única para cada objeto y no me importa si hay otros campos duplicados excepto este. Y quiero hacer de este objeto una clave para un Map. Entonces sobrescribimos los métodos hashCode() y equals() de esta manera:
private int id;
@Override
public int hashCode(){
return this.id;
}
@Override
public int equals(Object obj){
if(obj == null)
return false;
if(! obj instanceOf ThisClassName)
return false;
return this.id == obj.id;
}