Forem: Jordy Rodríguez

getFirst() y getLast(): Extrae elementos de listas en Java

Jordy Rodríguez — Sat, 27 Dec 2025 17:23:17 +0000

Cuando necesitas sacar el primer o el último elemento de una colección, getFirst() y getLast() te ahorran busquedas de índices y dolores de cabeza.

En mi día a día, trabajo con flujos de procesamiento donde las tareas llegan en orden y ciertas operaciones deben peekear extremos sin desordenarlos. En esas situaciones, tratar la estructura como un Deque (o usar LinkedList) y aprovechar getFirst/getLast te da claridad y menos errores que manipular índices manualmente.

getFirst() y getLast() funcionan como la forma directa de mirar los extremos de una cola o lista tratada como Deque. Para LinkedList, estos métodos están disponibles precisamente para operar al inicio o al final sin complicaciones. Importante: no eliminan el elemento; si quieres quitar, tienes removeFirst/removeLast o sus variantes seguras.

Cosas a tener en cuenta:

Si la estructura está vacía, getFirst() y getLast() lanzan NoSuchElementException.
Si solo quieres mirar sin posibilidad de excepción, usa peekFirst()/peekLast().
Si quieres extraer y eliminar al mismo tiempo, pollFirst()/pollLast() devuelve null cuando está vacía.

Ejemplo práctico (uso limpio en una lista que ya tiene elementos):

import java.util.Deque;
import java.util.LinkedList;

Deque<String> tareas = new LinkedList<>();
tareas.add("Diseñar"); tareas.add("Implementar"); tareas.add("Probar");

if (!tareas.isEmpty()) {
  String primero = tareas.getFirst();
  String ultimo = tareas.getLast();
}

Otra opción útil si solo quieres mirar sin riesgo de excepción:

import java.util.Deque;
import java.util.LinkedList;

Deque<String> tareas = new LinkedList<>();
tareas.add("Diseñar"); tareas.add("Implementar"); tareas.add("Probar");

String primeroPeek = tareas.peekFirst();
String ultimoPeek = tareas.peekLast();

Acción concreta para hacer hoy mismo:
Identifica en tu código una parte donde tomas el primer o último elemento de una Deque/LinkedList y refactorízala usando getFirst/getLast. Añade una comprobación de emptiness o, si solo quieres mirar sin costo, reemplázalo por peekFirst/peekLast. Pon a prueba con un caso vacío para ver que no explota y, si quieres, añade un pequeño test unitario que verifique ese comportamiento.

📬 Conecta Conmigo

El método repeat() en Java: Repite cadenas fácilmente

Jordy Rodríguez — Sat, 27 Dec 2025 17:14:35 +0000

Detrás de muchos logs y informes hay una pequeña línea que marca la diferencia: repetir texto sin líos. Con repeat() en Java, decimos adiós a los bucles para construir strings repetidos.

Esto importa en el día a día porque hago registros claros, separadores consistentes y columnas alineadas en informes automáticos. Una barra de separación bien definida o padding de columnas evita discusiones en los resultados y acelera la lectura de fallos.

El método repeat(int count) existe desde Java 11. Es una función de String que devuelve la cadena original repetida count veces. Si count es 0, obtienes una cadena vacía; si es negativo, se lanza IllegalArgumentException. Es directo: cadena.repeat(n).

Puede parecer trivial, pero es poderoso cuando necesitas consistencia sin complejidad. Úsalo para separar bloques de salida, construir encabezados de tablas o rellenar espacios para alineación. Ten en cuenta la memoria: repetir cadenas grandes muchas veces genera strings grandes; úsalo con tamaños razonables y evita usarlo en bucles de alto rendimiento sin medir.

Ejemplos prácticos

// Generar una línea de separación para logs
String sep = "-".repeat(40);
System.out.println(sep);

String name = "Jordy";
int width = 12;
String padded = name + " ".repeat(Math.max(0, width - name.length())) + "|";
System.out.println(padded);

Como muestra, puedo ver claridad inmediata en la salida y menos tareas de formateo manual. Si te sirve, usa repeat para crear encabezados, barras de progreso simples o para rellenar columnas en CSVs generados automáticamente.

Acción para hoy: identifica dos lugares en tu código donde concatentes manualmente para formatear salida y reemplázalos por repeat. Añade una barra separadora con '-'.repeat(40) y, si sales con columnas, usa padding con " ".repeat(...) para alinear. Verás la diferencia en legibilidad y mantenimiento.

📬 Conecta Conmigo

El nuevo instanceof en Java: Pattern Matching

Jordy Rodríguez — Sat, 27 Dec 2025 17:13:18 +0000

El cast ya no manda en tu código. El nuevo instanceof con Pattern Matching llega para que leer, entender y mantener el flujo sea más rápido.

En mi día a día lidio con APIs que devuelven Object, colecciones heterogéneas y eventos de distintas clases. Ver cada comprobación como un cast me rompe el ritmo; añade ruido, errores sutiles y pruebas repetitivas. Pattern Matching te da seguridad de tipo sin rebuscar en cada rama.

Con instanceof pattern matching, puedes declarar la variable del tipo directamente en la condición, y esa variable queda disponible dentro del bloque sin un cast explícito. Esto reduce líneas y elimina errores de ClassCastException por descuido.

Object o = obtenerDato();
if (o instanceof String s) {
  System.out.println("Largo: " + s.length());
} else {
  System.out.println("No es una cadena");
}

Si prefieres patters más declarativos, pattern matching para switch te permite escribir ramas por tipo sin duplicar lógica. Esto simplifica grandes estructuras de if/else.

static String describe(Object o) {
  return switch (o) {
    case String s -> "cadena: " + s;
    case Integer i -> "entero: " + i;
    default -> "otro";
  };
}

Hoy mismo: toma un método que use varios instanceof o un conjunto de if/else con casts y refactorízalo con pattern matching. Ejecuta la suite de tests y compara legibilidad y cantidad de líneas. Si funciona, comparte el before/after con tu equipo para acelerar futuras revisiones.

📬 Conecta Conmigo

Evita NullPointerException en Java

Jordy Rodríguez — Sat, 27 Dec 2025 17:07:52 +0000

Cada fallo en producción grita NPE. Un null en la entrada, un segundo más y el cliente ya no está conectado.

He visto esto demasiadas veces: estos nulls saltan cuando consumimos APIs, leemos datos de la base o manejamos configuración opcional. Un valor que llega null al otro lado del código estalla al dereferenciarlo, y el arreglo termina en hotfixes nocturnos.

Primero, diseña por contrato: no devuelvas null. Si no hay valor, usa un valor por defecto o envoltura con Optional. Nosotros ganamos previsibilidad y reducimos costos de debugging. Por ejemplo:

String username = Optional.ofNullable(user)
                          .map(User::getName)
                          .orElse("anonymous");

Además, aplica guardias tempranas para fail fast: valida entradas y evita que un null propague. Si un objeto es obligatorio, mantén su no-nullidad en todo el flujo. Ejemplo:

if (user == null) {
  throw new IllegalArgumentException("user is required");
}

Cierra con una acción concreta para hoy: identifica una ruta crítica donde puedas recibir null y refactorízala para usar Optional o, al menos, devolver un valor por defecto. Elige una llamada a servicio o lectura de datos que pueda devolver null y ponle un default o envoltura con Optional, luego verifica con tests simples de null-safety.

También tengo un video simple donde te muestra otra forma de evitar NPE:

📬 Conecta Conmigo

Simplifica comparaciones númericas con la clase Math en Java

Jordy Rodríguez — Sat, 27 Dec 2025 17:03:29 +0000

Un simple '==' entre doubles te traiciona. En la vida real, esas diferencias minúsculas pueden romper validaciones y decisiones de negocio.

En mi día a día me enfrento a cálculos que deben cuadrar con límites tolerables: distancias, tolerancias de sensores, resultados numéricos de física. Si comparo con ==, me encuentro con falsos negativos o positivos por diferencias que ni se ven en la UI. Para ordenar números, comparar a mano con a - b también puede fallar por overflow o NaN. Por eso conviene separar dos ideas: igualdad con tolerancia y ordenación estable.

La idea clave es simple: usa una tolerancia al comparar, y usa métodos de la clase Math para el orden. Para igualdad, calcula la diferencia y ajústala con una escala razonable; para ordenar, evita restas y usa Double.compare. Así reduces sorpresas en producción y haces que tu lógica sea determinista incluso con operaciones de precisión limitada.

Ejemplo práctico (una utilidad mínima):

public class MathUtils {
  public static boolean nearlyEqual(double a, double b, double eps) {
    double diff = Math.abs(a - b);
    if (diff <= eps) return true;
    double m = Math.max(Math.abs(a), Math.abs(b));
    return diff <= m * eps;
  }
  public static int compare(double a, double b) { return Double.compare(a, b); }
}

Usa la utilidad así: MathUtils.nearlyEqual(a, b, 1e-12). Si necesitas ordenar, usa MathUtils.compare(x, y) en lugar de restar.

Acción para hoy: identifica dos lugares críticos de tu código donde comparas doubles y aplica una comparación tolerante con nearlyEqual, además de reemplazar restas por Double.compare para cualquier ordenación. Si te sirve, empieza con un epsilon relativo de 1e-12 y ajústalo a tus rangos de negocio.

📬 Conecta Conmigo

El método isBlank() en Java: ¿En qué se diferencia de isEmpty()?

Jordy Rodríguez — Sat, 27 Dec 2025 17:00:08 +0000

IsBlank es tu arma secreta contra entradas que parecen vacías, pero no lo están. IsEmpty solo mira la longitud y se rompe con espacios, saltos o tabs.

En mi día a día, recibo payloads de clientes donde un campo llega como "" o como " " o con saltos de línea. Si me limito a isEmpty, esos casos pasan la validación y luego el backend falla al procesar datos invisibles. Con isBlank, una cadena que solo tiene whitespace ya no pasa como válida.

isBlank() verifica algo más profundo que la longitud: considera como vacío cualquier String que sea "" o que contenga únicamente caracteres de whitespace. isEmpty() solo devuelve true si la longitud es 0. Esto cambia la forma en que validamos inputs, logs y mensajes de error. Si quieres una validación de usuario robusta, usa isBlank para decidir “esto realmente está vacío” y reserva isEmpty para casos donde la ausencia de texto que no admite espacios sea lo que buscas.

La diferencia se nota sobre todo cuando hay datos que no ves a simple vista. Cualquier dato que no contribuya a la información real debe marcarse como inválido. Si en tu flujo te encuentras con nulos, recuerda que neither isBlank ni isEmpty protegen contra NPE por sí solos; añade un chequeo de null o usa una utilidad para normalizar antes de validar.

String a = "";
String b = "   ";
String c = "foo";

System.out.println(a.isEmpty()); // true
System.out.println(a.isBlank()); // true

System.out.println(b.isEmpty()); // false
System.out.println(b.isBlank()); // true

System.out.println(c.isBlank()); // false

Hoy mismo: revisa una validación de input en tu proyecto y cambia isEmpty por isBlank cuando quieras considerar whitespace como vacío. Añade un chequeo de null (por ejemplo, si el flujo puede recibir null) o crea una pequeña utilidad: boolean isBlankOrNull(String s) { return s == null || s.isBlank(); }. Implementa esa comprobación en al menos dos puntos del flujo de entrada y ejecuta tus pruebas para ver el ahorro en errores de usuario.

📬 Conecta Conmigo

Funciones con parámetros infinitos en Java

Jordy Rodríguez — Sat, 27 Dec 2025 16:57:59 +0000

¿Qué pasaría si una función pudiera aceptar 2, 5 o 20 argumentos sin cambiar su firma? Eso existe en Java: varargs, la forma elegante de manejar “parámetros infinitos”.

En mi día a día, los varargs me ahorran escribir métodos para cada aridad y me permiten construir APIs más fluidas. Piensa en un logger que acepte un formato y cualquier cantidad de argumentos, o en una utilidad que arme un mensaje a partir de tokens variables. Con varargs, lo complejo se queda en una firma simple y clara.

El truco está en que Java transforma ese parámetro variado en un arreglo del tipo correspondiente. Eso significa que, cada vez que llamas a un método con valores extra, se crea un array en tiempo de ejecución. Es rápido para casos simples, pero ojo: si el camino es crítico en rendimiento, evita usar varargs en hot paths o haz overloading para los casos más comunes. También limita la mezcla con tipos genéricos para evitar boxing innecesario.

Ejemplo práctico en código claro:

public class Utils {
  public static int sum(int... numbers) { int s = 0; for (int n : numbers) s += n; return s; }
  public static String join(String delimiter, String... tokens) { return String.join(delimiter, tokens); }
  public static void main(String[] args) {
    System.out.println(sum(1, 2, 3, 4));
    System.out.println(join(" - ", "A", "B", "C"));
  }
}

Lo ves: una misma firma para cualquier cantidad de entradas, utilizable en múltiples contextos sin boilerplate.

Hoy te propongo un paso concreto: identifica un método que tengas ya con dos o tres variantes de aridad (o que reciba un formato y argumentos). Reescribe esa firma para usar varargs y refactoriza dos o tres llamadas para ver la ganancia de claridad. Mide el cambio de legibilidad y, si hace daño en rendimiento, añade overloading para los casos más comunes.

📬 Conecta Conmigo

++ antes y ++ después en Java: Operador de incremento

Jordy Rodríguez — Sat, 27 Dec 2025 16:50:18 +0000

El ++ no es solo para sumar. En Java, pre y post increment pueden cambiar lo que tu código devuelve, no solo lo que guarda. Te lo digo con ejemplos reales que me pasaron en producción.

En mi día a día, el problema aparece cuando el incremento ocurre dentro de una expresión o al pasar el valor a un índice o a un método. A simple vista parece trivial, pero puede romper la lógica de un bucle o una llamada si confundes el momento en que se incrementa y se usa el valor.

El pre-incremento (++x) incrementa y devuelve el valor nuevo; el post-incremento (x++) devuelve el valor actual y luego lo incrementa. En bucles o en llamadas, elegir uno cambia el comportamiento. Si necesitas el valor ya incrementado para la operación siguiente, usa ++x; si necesitas el valor tal como está antes de incrementar, usa x++.

Ejemplo claro en código sencillo:

public class IncrementDemo {
  public static void main(String[] args) {
    int a = 1, b = ++a; // a=2, b=2
    int c = 1, d = c++; // c=2, d=1
    System.out.println(a + " " + b + " | " + c + " " + d);
  }
}

Este tipo de diferencias se ve a menudo cuando el incremento está ligado a una operación de índice o a la entrega de un valor a un método. Un mal uso puede hacer que la condición de un bucle se cumpla una iteración más o que un elemento se procese con el índice equivocado.

Acción para hoy mismo: revisa dos lugares en tu base de código donde utilices x++ para obtener el valor que se pasa a una próxima operación o a un índice. Cambia esos casos a ++x cuando el valor incrementado debe usarse inmediatamente, y agrega una pequeña prueba que compare el comportamiento con ambas variantes. Si no hay pruebas, escribe una de unidad que verifique explícitamente la diferencia entre pre y post en un escenario de contador o índice. Con eso ya ganas claridad y reduces bugs silenciosos.

📬 Conecta Conmigo

Separa números largo en Java con guiones bajos

Jordy Rodríguez — Sat, 27 Dec 2025 16:48:54 +0000

¿Cuántas veces te pierden los dígitos de un número gigante al mirar el código? En Java, escribe literales con guiones bajos y verás la diferencia al instante.

Yo lo aplico a diario: constantes financieras, contadores de pruebas y límites del sistema. No cambia la lógica, pero sí la legibilidad en la revisión de código.

Desde Java 7 puedes usar guiones bajos entre dígitos de literales enteros o long. No se pueden colocar al inicio o al final, junto al punto decimal, ni justo antes de la notación de tipo (L, F, D). En números hex o binarios también funcionan, pero me mantengo en decimal para evitar sorpresas. Mantener consistencia en todo el proyecto ayuda a que el equipo comprenda rápidamente la intención del número.

Mi regla práctica es simple: agrupa en bloques de tres dígitos para golpes visuales de millares, millones, etc. Usa L al final para long y evita usar guiones bajos en valores que ya tienen un significado especial (IDs generados, cadenas numéricas, etc.). Si alguien copia el literal, no debe haber ambigüedad.

public class ReadableLongs {
  public static void main(String[] args) {
    long max = 9_223_372_036_854_775_807L;
    long yearlyRevenue = 1_234_567_890_123_456L;
    System.out.println(max);
    System.out.println(yearlyRevenue);
  }
}

Acción para hoy mismo: identifica tres literales largos en tu código y refactorízalos para usar guiones bajos. Luego haz compile y corre tus tests para confirmar que todo sigue funcionando igual. Si puedes, hazlo en un PR pequeño y revisa con tu equipo para acordar la convención de formato.

📬 Conecta Conmigo

Final vs inmutable en Java: No son lo mismo

Jordy Rodríguez — Sat, 27 Dec 2025 04:30:14 +0000

Final no es inmutable. En Java, una referencia puede ser final y el objeto al que apunta seguir cambiando.

En mi día a día, veo APIs que devuelven listas mutables o exponen setters que permiten modificar el estado después de crear el objeto. Eso genera efectos colaterales difíciles de rastrear y pruebas más complicadas. Si queremos garantizar consistencia, necesitamos distinguir bien cuándo hablamos de la referencia y cuándo hablamos del estado del objeto.

El concepto en dos ideas rápidas:

Final: bloquea la re-asignación de la referencia, no el contenido. Puedes hacer esto y, aun así, manipular el objeto si es mutable.
Inmutable: el objeto no cambia después de su construcción. No expone mutadores y, si tiene colecciones, no las permite modificar desde fuera.

Ejemplos claros ayudan:

Final aplicado a una colección mutable

final List<String> items = new ArrayList<>();
items.add("alpha"); // OK
// items = new ArrayList<>(); // Error: cannot assign a value to final variable

Clase inmutable real

public final class UserId {
  private final String value;
  public UserId(String value) { this.value = value; }
  public String value() { return value; }
}

Una clase así no expone mutadores y su estado queda fijado al construirla.

Para lograr inmutabilidad real, cuida estos puntos:

campos privados y finales;
no permitas setters;
si expones datos mutables, devuelve copias defensivas o colecciones inmutables (por ejemplo, List.copyOf en Java 10+).

Hoy mismo: revisa una API que devuelve una List mutable. Ajusta para devolver una colección inmutable o una copia y añade una prueba que verifique que la lista no puede ser alterada por el consumidor. Si haces ese ajuste, ya ganamos claridad, seguridad y menos sorpresas en producción.

📬 Conecta Conmigo

Cadenas de texto en Java: TextBlocks

Jordy Rodríguez — Sat, 27 Dec 2025 04:21:58 +0000

Las cadenas largas en Java ya no se pelean con escapes. Con Text Blocks puedes escribir SQL, JSON o HTML tal como lo ves, sin convertir cada salto de línea en \n.

En el día a día de desarrollo, lidiamos con consultas acumuladas, fragmentos HTML embebidos y mensajes de error en formato JSON. Traducir todo eso a strings con escapes es una fuente constante de errores y mala legibilidad. Los Text Blocks cambian el juego: el código se ve como el contenido que representa.

Los Text Blocks son literales de texto entre tres comillas dobles. El contenido conserva saltos de línea y sangrías, y la indentación se normaliza para que puedas alinear el bloque con tu código sin romper el string. Puedes mezclar comillas simples y dobles sin problemas; no necesitas escapar comillas internas.

Cómo se usan en la práctica: crea un bloque como si pegaras el texto en un editor. Eso sí, evita dejar espacios al inicio que no quieras en el resultado final; si necesitas ajustar, puedes usar stripIndent() en la cadena resultante.

Código de ejemplo (SQL):

String sql = """
    SELECT id, name, email
    FROM customers
    WHERE status = ?
    AND created_at >= ?
    """;

Con este enfoque, las pruebas o los fixtures de JSON o HTML también quedan limpios en el día a día de los proyectos. Yo lo uso para declaraciones SQL dinámicas en repos y para generar respuestas de prueba en los servicios que montamos en 4SoftwareDevelopers. Menos escapes, menos ruido, menos caídas por errores de comillas.

Acción para hacer hoy: toma una cadena multi-línea que tengas en tu proyecto (una consulta, una plantilla JSON o HTML) y conviértela a un Text Block. Compila y ejecuta una prueba para verificar que el contenido se mantiene exactamente igual. Si ves sangrías extra, prueba con stripIndent().

📬 Conecta Conmigo

¿Qué es el Autoboxing y unboxing en Java?

Jordy Rodríguez — Sat, 27 Dec 2025 04:20:38 +0000

Autoboxing y unboxing en Java no son trucos mágicos; son el puente entre primitivos y objetos que usas cada día. Si ves List en tu código, ya estás en su territorio.

En el día a día importan porque te evitan escribir conversiones, pero cada conversión genera objetos y, en bucles apretados, eso suma. Entender cuándo sucede la conversión te ayuda a evitar hot spots de rendimiento y errores sutiles.

El concepto en corto: el autoboxing es la conversión automática de un primitivo a su wrapper (int -> Integer, real -> Double, etc.). El unboxing es al revés, cuando una clase envoltorio se usa como primitivo en operaciones aritméticas o comparaciones. Java también usa caché para wrappers de rango pequeño (-128 a 127), lo que evita crear nuevas instancias en muchos casos. Pero ojo: convertir null a un primitivo provoca NullPointerException, y el boxing/unboxing frecuente puede generar overhead de memoria y GC si lo haces en loops críticos.

Ejemplo práctico:

List<Integer> nums = new ArrayList<>();
for (int i = 0; i < 5; i++) {
    nums.add(i); // autoboxing: int -> Integer
}
int sum = 0;
for (Integer n : nums) {
    sum += n; // unboxing: Integer -> int
}

Este patrón es común: trabajas con colecciones de wrappers porque la API lo exige, pero luego haces cálculos con primitivos. El rendimiento mejora si evitas boxing innecesario en cuellos de botella y prefieres APIs que operan sobre primitivos cuando es posible.

Un vistazo rápido a riesgos reales: un Integer puede ser null; al despojarlo de su envoltorio en una operación, obtienes NPE. Y en bucles muy calientes, cada autoboxing implica asignaciones y posible recolección, lo que puede traer pausas inesperadas.

Hazlo hoy mismo

Revisa un método que recorra una List y haga sumas o cálculos. ¿Podrías usar un IntStream para evitar boxing innecesario? Por ejemplo, en lugar de sum += item, usa nums.stream().mapToInt(Integer::intValue).sum() y evita la conversión repetida.
Si trabajas con valores que pueden ser null, añade un filtro de nulls o usa un Optional para evitar NPEs.

Con un par de cambios pequeños, verás menos basura de objetos y choques de rendimiento sin perder la legibilidad ni la seguridad de tipos.