La estructura de 250 pies propuesta por Trump superaría en altura al Arco del Triunfo y a otros arcos triunfales de todo el mundo.
En el segundo día de QCon London 2026, Martin Kleppmann, disponible en LinkedIn, inició su discurso principal con un gráfico que no mostraba el rendimiento o la latencia de los sistemas, sino la cuota de mercado europea de la computación en la nube. AWS, Azure y Google Cloud controlan aproximadamente el setenta por ciento del mercado europeo, mientras que los proveedores de nube europeos más grandes apenas alcanzan el dos por ciento cada uno.
En otras palabras, Europa depende completamente de los servicios de nube estadounidenses.
Kleppmann, profesor asociado de la Universidad de Cambridge y autor de Designing Data-Intensive Applications (la segunda edición, co-escrita con Chris Riccomini, se publicará este mes), dedicó los siguientes cincuenta minutos a argumentar que esta dependencia es un riesgo que merece la pena abordar, no con pánico, sino con opciones tecnológicas prácticas que devuelvan el poder a los usuarios y lo alejen de los proveedores únicos.
Fundamentó el riesgo en acontecimientos recientes. El año pasado, las sanciones estadounidenses contra la Corte Penal Internacional en La Haya provocaron que el fiscal jefe perdiera el acceso a su correo electrónico alojado en Microsoft. Microsoft negó haber suspendido los servicios, pero confirmó que había estado en contacto con la CPI «a lo largo del proceso que resultó en la desconexión de su funcionario sancionado». La CPI migró fuera de los servicios de Microsoft poco después.
Dos semanas antes del discurso principal, Irán atacó tres centros de datos de AWS en los Emiratos Árabes Unidos con drones, dañando gravemente al menos uno. La región seguía mostrando servicios interrumpidos en el panel de control de AWS el día antes de la presentación. Kleppmann también señaló que alojar datos en regiones europeas tampoco resuelve el problema: Microsoft ha declarado que cumpliría con las solicitudes legales estadounidenses de datos de ciudadanos de la UE almacenados en la UE, independientemente de la legislación de la UE.
Su argumento no era que un conflicto entre Estados Unidos y Europa sea probable. Subrayó que la probabilidad sigue siendo pequeña, pero ya no es cero, y el impacto de un bloqueo repentino sería enorme. Esto hace que sea un riesgo que vale la pena mitigar bajo lo que él llamó «soberanía tecnológica«, una palabra de moda, reconoció, que no dice nada sobre cómo lograrla realmente.
Propuso tres direcciones tecnológicas concretas.
Multi-nube y commoditización: Para los servicios de back-end, Kleppmann argumentó que la capacidad de cambiar de proveedor es lo que importa, y que la commoditización a través de estándares de facto es el mejor camino para lograrlo. Señaló la API S3 para el almacenamiento de objetos, Kubernetes para la implementación, el protocolo Kafka para la transmisión y el protocolo de cable Postgres para las bases de datos como estándares emergentes que permiten cambiar incluso sin organismos de estandarización formales. Comparó esto con la estandarización de las roscas de los tornillos por Joseph Whitworth en 1841, que desbloqueó la intercambiabilidad entre los fabricantes durante la Revolución Industrial. Las contrapartidas son reales: aumento de los costes, complejidad operativa y quedarse atascado con funciones de menor denominador común. Kleppmann argumentó que los servicios commoditizados son muy preferibles a esperar que todos se auto-alojen.
La vida es demasiado corta para ser un administrador de sistemas, a menos que realmente te guste, o a menos que sea tu trabajo.
El protocolo AT y Bluesky: Para las redes sociales, Kleppmann describió el protocolo AT subyacente a Bluesky, en el que ha asesorado desde principios de 2022. El protocolo fue diseñado en torno a la «salida creíble», el principio de que si un proveedor se comporta mal, los usuarios pueden cambiar sin perder su nombre de usuario, su grafo social o sus publicaciones. Los datos de cada usuario residen en un repositorio personal (análogo a un repositorio Git) alojado en un servidor de datos personal (PDS), y cualquiera puede ejecutar un PDS. Un relé agrega eventos de todos los repositorios en un flujo de datos, y AppViews construye índices sobre él.
Cada componente puede ser ejecutado por proveedores competidores. El directorio de usuarios (directorio PLC) sigue siendo centralizado, pero con protecciones de integridad criptográfica y la opción de bifurcaciones comunitarias si se comporta mal. Bluesky también está llevando los protocolos básicos a la IETF para su estandarización formal, renunciando al control corporativo en el proceso. Actualmente hay cuarenta y tres millones de usuarios y un ecosistema en crecimiento de aplicaciones no de microblogging, blogs, codificación social, intercambio de vídeos y reseñas de libros, todos construidos sobre el mismo protocolo. Para una inmersión técnica más profunda, Kleppmann señaló el documento de arquitectura que co-autorizó.
Software local-first: Para las herramientas de colaboración, Kleppmann describió el software local-first como la combinación de lo mejor de Google Sheets (datos ricos, colaboración en tiempo real, usabilidad) con lo mejor de Git (control de versiones, ramificación, alojamiento multi-proveedor, archivos en su propia máquina). El cambio fundamental: la copia local de datos del usuario se convierte en primaria, con los servicios en la nube reducidos a la sincronización y la copia de seguridad. Esto minimiza el papel de los servidores centralizados, hace que cambiar de proveedor sea trivial e incluso permite la sincronización entre pares.
El enfoque se deriva de la investigación sobre CRDT (tipos de datos replicados sin conflictos) y el proyecto de código abierto Automerge, que Kleppmann co-creó en 2017. El término «local-first» se acuñó en un ensayo de 2019 que desde entonces ha desencadenado un movimiento, con conferencias, startups, podcasts y un documental con la Conferencia Local-First que regresa a Berlín en julio de 2026. Kleppmann señaló que local-first funciona bien para la edición de archivos y las herramientas de productividad, pero no es adecuado para los sistemas que gestionan recursos físicos, como las cuentas bancarias, donde una fuente centralizada y autorizada sigue siendo apropiada.
El hilo conductor de los tres, dijo, es que la commoditización y la descentralización cambian el equilibrio de poder. La dependencia crea influencia, ya sea el suministro de gas de un país o el proveedor de nube de una empresa, y las elecciones de ingeniería que hacemos determinan quién tiene esa influencia.
Kleppmann concluyó:
Usar la tecnología para devolver el poder a los usuarios permite una mayor libertad y cambia el equilibrio de poder. Tal vez sea algo en lo que debas pensar en tu propio trabajo.
Esta semana, el resumen de Java del 23 de febrero de 2026, destaca: una nueva versión Candidata de JEP 531, Constantes Lazy; lanzamientos GA de TornadoVM 3.0 y NetBeans 29; lanzamientos puntuales de Quarkus, JReleaser, Chicory y RefactorFirst; lanzamientos de mantenimiento de Micronaut y Jox; y la edición de febrero de 2026 de Open Liberty.
OpenJDK
JEP 531, Constantes Lazy (Tercera Vista Previa), ha sido elevado de su estado JEP Draft 8329758 a Candidato. Anteriormente conocido como StableValues, esta característica propone una tercera vista previa, con dos cambios, después de dos rondas de vista previa entregadas en la próxima versión de JDK 26 y JDK 25. Los cambios incluyen: la eliminación de los métodos, isInitialized() y orElse(), de la interfaz LazyConstant, ya que no se alinean con los objetivos de diseño de esta característica; y un nuevo método de fábrica, ofLazy(), que puede crear elementos estables y predefinidos para los tres tipos de colección Java, a saber: List, Set y Map.
JDK 26
Build 35 sigue siendo la compilación actual en las compilaciones de acceso anticipado de JDK 26 . Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
JDK 27
Build 11 de las compilaciones de acceso anticipado de JDK 27 estuvo disponible la semana pasada con actualizaciones de Build 10 que incluyen correcciones para varios problemas. Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
Para JDK 26 y JDK 27, se anima a los desarrolladores a informar de errores a través de la Base de datos de errores de Java.
TornadoVM
El lanzamiento GA de TornadoVM 3.0.0 ofrece correcciones de errores, actualizaciones de dependencias y cambios notables como: una refactorización de la generación del proyecto IntelliJ que elimina la bandera de línea de comandos para el usuario final, --intellijinit, a favor de un flujo de trabajo solo para desarrolladores para garantizar que los desarrolladores puedan configurar su IDE y cambiar más fácilmente entre backends; y una refactorización de sus acciones de GitHub para dividir las pruebas, el empaquetado y el despliegue de JDK 21 y JDK 25. Más detalles sobre esta versión se pueden encontrar en las notas de la versión para versión JDK 25 y versión JDK 21.
Apache NetBeans
El lanzamiento de Apache NetBeans 29 incluye correcciones de errores, actualizaciones de dependencias y nuevas características como: un rendimiento de inicialización mejorado en la clase LazyProject; una resolución de advertencias de una instancia de la clase NotificationCenterManager al sincronizar las solicitudes de manipulación de una lista filtrada; y una actualización de la clase DefaultGitHyperlinkProvider para admitir proyectos de Codeberg. Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
Open Liberty
El lanzamiento GA de Open Liberty 26.0.0.2 presenta: soporte para Java Toolchains en Liberty Build Plugins que permite a los desarrolladores separar el JDK utilizado con las herramientas de compilación del JDK utilizado para ejecutar el servidor Liberty y sus aplicaciones relacionadas; y una resolución de CVE-2025-14914, una vulnerabilidad de ejecución remota de código, que afecta a las versiones de Open Liberty 17.0.0.3 a 26.0.0.1, que permite a un atacante, como usuario con privilegios, cargar un archivo ZIP con secuencias de recorrido de ruta para sobrescribir archivos y ejecutar código arbitrario.
Quarkus
El lanzamiento de Quarkus 3.32 proporciona correcciones de errores, actualizaciones de dependencias y nuevas características como: integración con Project Leyden, soporte para el registro automático de servicios de aplicaciones Quarkus utilizando un registrador de servicios como la extensión Quarkus SmallRye Stork; y un apagado más elegante que evita un código de estado HTTP 503, Servicio no disponible, tanto como sea posible durante el proceso. Más detalles sobre esta versión se pueden encontrar en las notas de la versión para versión 3.32.1 y versión 3.32.0.
Micronaut
La Fundación Micronaut ha lanzado la versión 4.10.9 del Micronaut Framework basada en Micronaut Core 4.10.6, con correcciones de errores y actualizaciones de parches a los módulos: Micronaut Servlet, Micronaut for Spring y Micronaut MCP. Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
JReleaser
La versión 1.23.0 de JReleaser, una utilidad Java que agiliza la creación de lanzamientos de proyectos, ha sido lanzada con correcciones de errores, mejoras de la documentación, actualizaciones de dependencias y nuevas características como: la adición de una propiedad paths a la clase ChangelogGenerator y la interfaz Changelog para admitir el filtrado de commits solo a aquellos que afectan rutas especificadas; y una actualización de la clase ChronVer para permitir una regla de formato de tiempo más indulgente según la especificación ChronVer. Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
Chicory
El lanzamiento de Chicory 1.7.0, un entorno de ejecución WebAssembly nativo de JVM, presenta soporte para: la Propuesta de GC para WebAssembly (WasmGC), que permite tipos de estructura y matriz recolectados por basura en módulos WebAssembly; y la Propuesta de Memoria Múltiple para WebAssembly que permite a los módulos WebAssembly declarar y acceder simultáneamente a múltiples instancias de memoria. Estas nuevas características acercan a Chicory un paso más al cumplimiento total de la especificación Wasm 3.0.
RefactorFirst
Jim Bethancourt, Consultor Principal de Software en Improving, ha lanzado la versión 0.8.0 de RefactorFirst, una utilidad que prioriza las partes de una aplicación que deben refactorizarse. Este lanzamiento ofrece: la eliminación de dos métodos no utilizados, gitRepository() y listRepositoryContentsAtHEAD(), de la clase GitLogReader que redujo el uso de memoria de Eclipse JGit; y una resolución de una NullPointerException al intentar una búsqueda de Git debido a las clases generadas y su historial asociado que no existían en Git. Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
Jox
El lanzamiento de Jox 1.1.2-channels, una biblioteca de hilos virtuales que implementa una estructura de datos Channel eficiente en Java diseñada para ser utilizada con hilos virtuales, presenta cambios notables como: implementaciones de métodos no bloqueantes, trySend() y tryReceive(), agregados a la clase Channel y las interfaces Sink y Source, para la integración con marcos no bloqueantes como Netty y Vert.x; y una resolución de un fallo de una acción de Release Drafter de GitHub en eventos pull_request debido a que GitHub establece la referencia a un commit de fusión temporal. Más detalles sobre esta versión se pueden encontrar en las notas de la versión.
En QCon AI NY 2025, Tracy Bannon presentó una charla en la que examinó cómo la rápida adopción de agentes de IA está remodelando los sistemas de software, y por qué las organizaciones corren el riesgo de repetir errores arquitectónicos familiares si tratan toda la “IA” o los “agentes” como intercambiables.
Bannon argumentó que gran parte de la confusión actual proviene de agrupar comportamientos y perfiles de riesgo muy diferentes bajo las mismas etiquetas. Los bots fueron descritos como respondedores basados en scripts que reaccionan a desencadenantes predefinidos, mientras que los asistentes colaboran con humanos y permanecen en gran medida bajo control humano. Los agentes, por el contrario, son actores orientados a objetivos capaces de tomar decisiones y realizar acciones en varios sistemas.
Todos hablan de la ‘productividad’ de la IA. Muy pocos hablan de la amnesia arquitectónica que conlleva. – Tracy Bannon
Para concretar, Bannon delineó un conjunto de patrones de autonomía que comúnmente aparecen a lo largo del ciclo de vida del desarrollo de software. Estos iban desde herramientas asistidas por IA integradas en flujos de trabajo existentes, hasta agentes a nivel de tarea que operan dentro de ámbitos delimitados, pasando por la orquestación multiagente que coordina flujos de extremo a extremo, y finalmente, la autonomía a nivel de misión donde los sistemas planifican, optimizan y se adaptan hacia objetivos de nivel superior.
Un tema central de la charla fue que la autonomía no falla por sí sola; las fallas ocurren cuando la autonomía crece más rápido que la disciplina arquitectónica. Bannon describió esta brecha como la producción de lo que ella llamó “deuda agentiva”. Conectó la deuda agentiva a áreas problemáticas familiares como la proliferación de identidades y permisos, la segmentación y contención insuficientes, la falta de linaje y observabilidad, y las comprobaciones de validación y seguridad débiles.
Bannon vinculó este riesgo a tendencias más amplias de la industria, señalando investigaciones que indican que una gran mayoría de los responsables de la toma de decisiones tecnológicas esperan que la gravedad de la deuda técnica aumente a corto plazo debido a la complejidad impulsada por la IA. Argumentó que la IA no introduce modos de falla fundamentalmente nuevos, sino que amplifica los existentes al acelerar el cambio y aumentar el radio de impacto de los errores.
Se centró en aplicar principios arquitectónicos establecidos a los sistemas agentivos. Argumentó que las organizaciones ya saben cómo gestionar el riesgo en sistemas distribuidos, pero a menudo olvidan estas lecciones bajo la presión de avanzar más rápido. La gobernanza, en este contexto, se presentó como el conjunto mínimo de controles necesarios para generar confianza, incluida la rendición de cuentas y la trazabilidad claras de las acciones y los flujos de datos.
La identidad se destacó como el control fundamental sobre el que dependen otras salvaguardias. Bannon afirmó que cada agente debe tener una identidad única y revocable, y que las organizaciones deberían poder responder rápidamente a preguntas básicas cuando algo sale mal: a qué puede acceder el agente, qué acciones ha realizado y cómo se puede detener. Describió un patrón de identidad mínimo que consiste en un registro de agentes.
Perseguimos métricas de actividad visibles… y silenciosamente descuidamos el trabajo que mantiene los sistemas saludables: diseño, refactorización, validación, modelado de amenazas. – Tracy Bannon
La disciplina en la toma de decisiones fue otro tema recurrente. Bannon animó a los equipos a empezar por el “por qué” en lugar del “cómo”, y a hacer explícitos los compromisos antes de aumentar la autonomía. Describió las decisiones como optimizaciones que siempre mejoran una dimensión a expensas de otra, como el valor frente al esfuerzo o la velocidad frente a la calidad.
La charla concluyó con un llamamiento a los arquitectos y los ingenieros sénior para que desempeñen un papel activo en la configuración de la forma en que se introducen los agentes de IA. Bannon enmarcó esta responsabilidad como la prevención de la amnesia arquitectónica mediante el diseño de agentes gobernados en lugar de automatizaciones ad hoc, la visibilización del riesgo y la deuda, y la búsqueda de niveles de autonomía más altos solo donde aporten un valor claro. Su mensaje final fue que las prácticas básicas de la arquitectura de software siguen siendo válidas, y que el desafío no es aprender disciplinas completamente nuevas.
Los desarrolladores que deseen obtener más información pueden explorar sesiones adicionales de QCon AI y la cobertura de InfoQ, con videos grabados de la conferencia que se espera estén disponibles a partir del 15 de enero de 2026.
En 1972, Kisho Kurokawa (1934-2007), uno de los arquitectos más jóvenes y visionarios de su generación, completaba su obra más audaz: la Nakagin Capsule Tower. Este edificio, un símbolo de modernización, se componía de dos núcleos de hormigón y acero a los que se adosaban 140 cápsulas prefabricadas, cada una de aproximadamente diez metros cuadrados, equipadas con baño, mobiliario integrado y electrodomésticos. Su icónica ventana circular servía como único punto de conexión con el exterior.
De empleados de oficina a comunidad creativa
Originalmente concebida para los salarymen (empleados de bajo rango en Japón) que se desplazaban en tren, trabajaban en oficinas y hoteles, la torre proponía un modelo compacto y modular de vida urbana. Con el tiempo, la teoría se transformó en práctica: muchas cápsulas fueron reutilizadas como oficinas, salas de té, mini galerías o incluso cabinas de DJ. La realidad aplicó la flexibilidad que el sistema industrial no había logrado alcanzar. Entre los residentes más comprometidos se encontraba Tatsuyuki Maeda, quien explica: «Compré mi primera cápsula en 2010 y terminé con 15. Al principio me atrajo la idea teórica del edificio, pero pronto me fascinó mucho más la comunidad creativa que se había formado en su interior».
© Noritaka Minami
El declive de un sueño arquitectónico
Sin embargo, el deterioro del edificio era inevitable. El envejecimiento de las instalaciones, especialmente el núcleo estructural y la fontanería, junto con las estrictas regulaciones sísmicas japonesas, hicieron inviable una rehabilitación integral. «El envejecimiento del núcleo estructural fue la principal causa», admite Maeda, «y la pandemia de COVID-19 imposibilitó la atracción de inversión extranjera». En 2022, ya envuelta en redes de protección contra desprendimientos, la Nakagin Capsule Tower fue desmantelada y demolida. Antes de su desaparición, varios residentes colaboraron con el especialista en documentación arquitectónica Yuta Tokunaga para generar un modelo 3D de alta precisión que preservara su memoria espacial.
El proyecto TornadoVM ha alcanzado recientemente la versión 2.0, un hito importante para este proyecto de código abierto que tiene como objetivo proporcionar un entorno de ejecución heterogéneo para Java. Este lanzamiento es especialmente relevante para los equipos que desarrollan soluciones de LLM en la JVM.
El proyecto acelera automáticamente los programas Java en CPUs multinúcleo, GPUs y FPGAs. No reemplaza a las JVM existentes, sino que añade la capacidad de descargar código Java a los backends, gestionando la memoria entre Java y los aceleradores de hardware, y ejecutando los kernels de cálculo. Esta capacidad proporciona un componente clave para las cargas de trabajo modernas en la nube y el aprendizaje automático.
InfoQ ya había cubierto el proyecto en 2020 y en 2022.
TornadoVM compila el bytecode de Java en tiempo de ejecución (actuando como un compilador JIT) a uno de tres backends: OpenCL C, NVIDIA CUDA PTX y SPIR-V binary. Los desarrolladores pueden elegir qué backends instalar y ejecutar según sus sistemas específicos.
Es importante tener en cuenta que no todos los tipos de computación Java son adecuados para ser descargados a TornadoVM. Por ejemplo, las cargas de trabajo con bucles ‘for’ que no tienen dependencias entre iteraciones son muy buenas candidatas, ya que permiten la computación en paralelo.
En particular, las aplicaciones basadas en matrices, como el aprendizaje automático y el aprendizaje profundo, son buenos candidatos. Otros ejemplos de este patrón son las simulaciones físicas (por ejemplo, la computación de partículas N-cuerpo), las aplicaciones financieras como Black-Scholes, y una variedad de aplicaciones en visión artificial, fotografía computacional, procesamiento del lenguaje natural y procesamiento de señales.
TornadoVM ofrece dos formas complementarias de expresar el paralelismo: la API Loop Parallel, que utiliza anotaciones Java como @Parallel y @Reduce para paralelizar bucles, y la API Kernel, que utiliza un KernelContext para la programación explícita de estilo GPU (con conceptos como ID de hilos, memoria local, barreras disponibles), y que es similar a CUDA/OpenCL/SYCL.
La API Loop Parallel puede ser tan simple como añadir una anotación de tipo:
public static void vectorMul(FloatArray a, FloatArray b, FloatArray result) {
for (@Parallel int i = 0; i
Mientras que el estilo Kernel Context construye explícitamente un TaskGraph como un objeto Java, de la siguiente manera:
var taskGraph = new TaskGraph("multiply")
.transferToDevice(DataTransferMode.FIRST_EXECUTION, a, b)
.task("vectorMul", Example::vectorMul, a, b, result)
.transferToHost(DataTransferMode.EVERY_EXECUTION, result);
var snapshot = taskGraph.snapshot();
new TornadoExecutionPlan(snapshot).execute();
El equipo también está lanzando una biblioteca completa de inferencia de LLM construida con él en Java puro que proporciona inferencia de LLM en GPUs, todo en Java sin dependencias externas.
La reciente versión v0.3.0 de GPULlama3.java trae consigo mejoras significativas en rendimiento y usabilidad.
- ~30% de aumento en el rendimiento en GPUs NVIDIA (tokens/segundo)
- Generación de kernels FP16 y Q8 optimizada.
- Configuración más sencilla gracias a los nuevos SDK de TornadoVM: no requiere una configuración compleja de la GPU.
- Funciona en NVIDIA PTX, OpenCL y soporte temprano para Apple Silicon.
- Soporte mejorado para Quarkus
- Integración con LangChain4j
GPULlama3.java actualmente soporta varios modelos FP16 (punto flotante de 16 bits) y cuantificados de 8 bits, en el rango de los miles de millones de parámetros:
- Llama 3.2 (1B) – FP16
- Llama 3.2 (3B) – FP16
- Llama 3 (8B) – FP16
- Mistral (7B) – FP16
- Qwen3 (0.6B) – FP16
- Qwen3 (1.7B) – FP16
- Qwen3 (4B) – FP16
- Qwen3 (8B) – FP16
- Phi-3-mini-4k – FP16
- Qwen2.5 (0.5B)
- Qwen2.5 (1.5B)
- DeepSeek-R1-Distill-Qwen (1.5B)
Dependiendo del modelo seleccionado, se construirá un plan de ejecución diferente, correspondiente a la arquitectura del modelo relevante.
El proyecto está liderado por el laboratorio Beehive, que forma parte del Grupo de Tecnologías Avanzadas de Procesadores de la Universidad de Manchester, especializado en el codesarrollo de soluciones combinadas de hardware y software.
El equipo también ha desarrollado TornadoInsight, un plugin para IntelliJ IDEA que mejora la experiencia del desarrollador al trabajar con TornadoVM.
El trabajo futuro en la hoja de ruta incluye hacer que TornadoVM esté disponible en SDKman y trasladar los componentes JNI en el código base para que utilicen la nueva API FFM en su lugar.