Rust en la JVM gracias a Panama es en

La JVM es una obra de ingeniería que hace que Java (y otros lenguajes) sea increíblemente rápido para la mayoría de las cargas de trabajo. Pero a veces, "rápido" no es suficiente. En dominios como la computación científica, la IA o el procesamiento de volúmenes masivos de texto, necesitamos invocar bibliotecas nativas altamente optimizadas (escritas en C++ o Rust) para obtener una ventaja de rendimiento crítica o acceder a funcionalidades que no están disponibles en la JVM. Durante décadas, la única opción fue usar la Java Native Interface (JNI), un puente hacia el mundo nativo tan potente como complejo e inseguro.

Aquí es donde entra en juego Project Panama. Gracias a la Foreign Function & Memory API (FFM) incluida en Project Panama, Java finalmente ofrece una forma segura, elegante y con soporte oficial para llamar a código nativo, eliminando la necesidad de escribir código de interconexión y de la gestión manual de memoria. En esta charla usaré FFM para solucionar un desafío clásico en Java: el motor de expresiones regulares.

Acompáñame en una sesión práctica en la que reemplazaremos el motor de regex de Java, que es funcional pero a menudo ineficiente, por el crate de regex de Rust, altamente optimizado. Implementaremos la solución de dos formas, una al lado de la otra: "a la antigua" con JNI y "a la moderna" con Project Panama. Para rematar, compararemos el rendimiento de ambas soluciones frente a las expresiones regulares estándar de Java, lo cual servirá para entender no solo cómo invocar código nativo, sino también cuándo realmente merece la pena el esfuerzo y cuándo no.

Esta charla presenta la alternativa moderna a JNI: el Project Panama. En la charla mostraré cómo usar el crate "regex" de Rust desde Java mediante JNI y Project Panama.

Los asistentes no solo aprenderán sobre una nueva funcionalidad. Verán cómo resuelve un problema del mundo real y aprenderán cuándo merece la pena dar el salto a nativo y cuándo no.

Native Speed, Java Comfort: Calling Rust from the JVM with Project Panama es en

The JVM is one of the most impressive pieces of software engineering, making Java incredibly fast for most workloads. But sometimes, "fast" isn't enough. For domains like scientific computing, AI, or processing massive volumes of text, we need to call highly-optimized native libraries written in C++ or Rust to gain a critical performance edge or access functionality not available on the JVM. For decades, this meant using the Java Native Interface (JNI)—a powerful but notoriously complex and unsafe bridge to the native world.

Enter Project Panama. With the Foreign Function & Memory (FFM) API, Java finally has a safe, supported, and elegant way to call native code, eliminating the need for brittle glue code and manual memory management. This talk puts it to the test with a classic Java challenge: the regular expression engine.

Join me for a practical, hands-on session where we will replace Java's capable but often-outperformed regex engine with Rust's highly optimized regex crate. We will walk through two implementations side-by-side: the "old way" with JNI and the "new way" with Project Panama. You will see firsthand how Panama simplifies interfacing with native code and improves safety. We'll cap it off with live benchmarks to compare the performance of both approaches against standard Java regex, helping you understand not just how to call native code, but also when it's truly worth the effort.

This talk presents the modern alternative to JNI: Project Panama. In the session, I will demonstrate how to use Rust's "regex" crate from Java using both JNI and Project Panama.

Attendees will not just learn about a new feature. They will see how it solves a real-world problem and learn when it's worth making the jump to native code—and when it's not.

Manage memory in the JVM as if it were C en

As in many other languages, in Java heap memory is managed. That is, the program explicitly reserves memory, but does not indicate when to free it and delegates it to the garbage collector.

This way to deal with memory has several advantages, but it also has some drawbacks that become more problematic when the program has to work with a large amount of data or process it very quickly. For example systems like Apache Kafka or databases like Apache Pinot largely avoid using managed memory and instead manually allocate and free memory in what is known as offheap memory.

This is a technical and practical talk about how to use this memory in the JVM, when it's worth using it, and how it affects our code and deployments including examples in real applications and libraries.

Deep Dive into Apache Pinot’s Multi-Stage Query Engine: Architecture and Performance en

Apache Pinot is an open-source, real-time distributed database for low-latency, high-throughput queries on large-scale datasets. As industries like e-commerce and IoT demand real-time analytics, Pinot's original single-stage query engine (SSQE) struggled with complex queries involving joins and window functions.

The Multi-Stage Query Engine (MSQE) addresses these challenges, enabling advanced relational operators and supporting complex query execution. In this session, we’ll delve into MSQE’s key innovations, including its integration with Apache Calcite for smart query planning and gRPC for efficient inter-server communication. We’ll also explore strategies for optimizing data shuffling, thread management, and query execution statistics to scale across large environments.

Join us to discover how MSQE extends Pinot’s capabilities, overcomes its limitations, and transforms it into a robust solution for modern data analysis.

Why Your SQL is Slow: Unmasking Hidden Performance Traps in Apache Pinot en

As developers, we've all been there: you write a SQL query that looks perfectly clean and correct, but it runs unexpectedly slow. You check the execution plan and find the database has chosen a brute-force, inefficient path. This is a problem in single-node databases like Postgres, but it is even worse in distributed ones.

Apache Pinot is a distributed OLAP database that can run complex SQL expressions (including window functions and joins) in milliseconds across billions of rows. However, its optimizer applies complex relational algebra transformations while remaining blind to business invariants known only to humans (and sometimes not even them).

This means that a seemingly harmless function call, an innocent offset or limit, the subtle properties of NULL handling, or a slight change in a JOIN condition can unknowingly prevent these transformations, forcing the engine to abandon powerful optimizations. To make matters worse, ORMs like Hibernate are notorious for generating queries that fall into these exact traps.

While this talk uses Apache Pinot for its examples, the concepts are universal. Whether you're using ClickHouse, traditional single-node SQL databases, or even NoSQL databases like MongoDB, the principles for writing optimizer-friendly queries remain the same. Using concrete, real-world examples, I will demonstrate how seemingly equivalent SQL queries can produce wildly different execution plans. You'll leave this talk armed with the knowledge to spot these "optimization killers" and craft queries that work with the database, not against it, ensuring your analytics are always blazingly fast.

This talk tackles a universal developer pain point: writing a "perfect" SQL query that runs inexplicably slowly. Using the Apache Pinot distributed database as a practical case study, I will demystify why this happens.

The session dives into how developers unknowingly sabotage their own queries through subtle NULL semantics, innocent-looking functions, and ORM-generated code that breaks the relational algebra rules core to any modern optimizer.

This is a highly practical, "code-and-consequences" session that will give attendees a new mental model for writing performant SQL that applies not just to Pinot, but to any database they use.