Skip to main content

Gestión de dependencias de Java: ¿cuántas líneas de código tiene mi aplicación?

Escrito por
Java engineering feature

12 de agosto de 2020

0 minutos de lectura

Hace unas semanas tuve la oportunidad de dar una presentación en la conferencia neerlandesa de Java JSpring. La charla trató sobre la gestión de dependencias de Java.

Durante esta charla, creé una aplicación sencilla con Spring Boot y calculé cuántas líneas aportaban mis dependencias de Java en comparación con las que escribí. La idea era mostrar que las dependencias ocupan una gran parte de tu aplicación y también requieren atención. Después de la presentación, publiqué el siguiente tuit, que recibió mucha atención y me motivó a escribir esta publicación:

Cómo calcular cuántas líneas aportan mis dependencias de Java

Paso 1: Generar una aplicación con Spring Boot

Para empezar, creé una aplicación con Spring Boot usando Spring Boot Initialzr, con web como única dependencia.

Página de Spring Initializr que muestra la dependencia Spring Web seleccionada, junto con los metadatos del proyecto y las opciones de versión de Java.

Esto significa, básicamente, que mi proyecto contiene spring-boot-starter-web como única dependencia directa.

Paso 2: Crear un controlador REST

Después, escribí el endpoint REST más sencillo que puedas imaginar, en solo 4 líneas:

@RestController
public class Controller {

   @GetMapping("/hello")
   public String hello() {  return "hello"; }
}

Paso 3: Crear el archivo jar para la implementación

El archivo jar que se genera a partir de este proyecto Java es un jar con todo incluido, que contiene todos los archivos jar de los que depende el proyecto. Esto se debe a que Spring Boot incluye el servidor de aplicaciones junto con la propia aplicación.

Paso 4: Analizar el archivo jar

Lo siguiente que hice fue crear una aplicación sencilla que consume el archivo jar de Spring Boot generado. Esta descomprime el archivo jar y todas las dependencias que contiene. Luego, descompila todos los archivos de clase de los jars y cuenta las líneas de código.

Paso 5: Recopilar los resultados

  • Líneas de código escritas: 4

  • Archivos jar: 33

  • Archivos de clase: 9917

  • Líneas de código: 518772

Algunas notas sobre las cifras

Las cifras anteriores están lejos de ser precisas. Las líneas en blanco y las que solo contienen un corchete no se incluyeron en el recuento final.

Es debatible si deberíamos analizar mejor estas líneas y excluir aún más para obtener cifras más precisas. Además, los distintos descompiladores arrojan resultados diferentes.

Considero que esto es más bien una pseudociencia. Aunque las cifras no son precisas, sí muestran el importante papel que desempeñan las dependencias en nuestras aplicaciones. Ese era mi objetivo.

Cuida tus dependencias de Java

De acuerdo, las cifras son altas, pero ¿qué nos dice realmente este ejemplo? Para empezar, usar Spring Boot para una aplicación de «Hola, mundo» es excesivo. Además, Spring Boot es un servidor de aplicaciones, así que estas cifras altas son de esperarse, ¿no?

Todas estas observaciones son ciertas. Estoy de acuerdo en que este es el endpoint REST más inútil que podrías escribir. Sin embargo, esto destaca que las dependencias representan un gran porcentaje del binario que ponemos en producción. Como Spring Boot es un framework que usan muchísimos desarrolladores de Java, lo elegí deliberadamente para este ejemplo.

Piénsalo. En este ejemplo, las líneas de código que escribí representan mucho menos del 1 % del total de líneas de código que ponemos en producción. Sin embargo, como equipo somos responsables de todas ellas. Si algo falla en la aplicación, el equipo de desarrollo debe resolverlo. Prácticas como la revisión de código, la programación en pareja y el análisis estático automatizado ayudan sin duda a crear una mejor base de código. Pero ¿qué pasa con el 99 % del código que usamos y del que dependemos tanto?

Es esencial cuidar tus dependencias y actualizarlas a tiempo. Importar un paquete implica muchas dependencias y muchos posibles vectores de ataque. Todo equipo de desarrollo debería considerar crear una estrategia de gestión de dependencias de Java que defina cómo se eligen, actualizan y eliminan las dependencias. Desde el punto de vista de la seguridad, como mínimo deberías recibir una alerta si alguna de tus dependencias, o dependencias transitivas, tiene una vulnerabilidad.

Analizar tu aplicación con Snyk para detectar vulnerabilidades en tus dependencias de código abierto puede ayudarte con esto. Snyk se puede usar en todas las etapas del ciclo de vida del desarrollo de software (SDLC) y es muy adaptable, por lo que resulta ideal para la automatización. Snyk no solo detecta vulnerabilidades: también ayuda a detectarlas lo antes posible.

Conclusión

No siempre basta con cuidar bien nuestro código; también debemos prestar atención a nuestras dependencias, ya que cumplen un papel enorme en nuestras aplicaciones.

Analizar tus dependencias con herramientas como Snyk ayuda a evitar que las vulnerabilidades pasen inadvertidas. Además, implementar una estrategia sólida de gestión de dependencias de Java es fundamental para que tu aplicación sea fácil de mantener, escalable, predecible y, sobre todo, segura.

Comienza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.

Leer más

blog feature snyk container custom base recommendations
Blog

Presentamos Evo Agentic AppSec: seguridad que sigue el ritmo del desarrollo con IA

El desarrollo impulsado por IA avanza más rápido que los flujos de trabajo de seguridad tradicionales. Agentic AppSec de Snyk usa agentes de seguridad para encontrar, corregir y verificar vulnerabilidades de forma continua, mientras las personas establecen el nivel.

blog feature ai violet
Blog

VulnBump: ¿Pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación?

VulnBump prueba agentes de IA con 307 actualizaciones reales de dependencias. Una corrección cuenta solo si elimina la vulnerabilidad y la compilación y las pruebas siguen pasando.

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.