Friday, June 25, 2021
Applications in a microservices architecture can communicate with each other in different ways. Adopting an event-driven paradigm based on asynchronous messaging provides services a way of communicating while reducing runtime coupling. Functions are a natural way of implementing event-driven business logic in terms of suppliers, processors, and consumers. Furthermore, when going serverless, we aim at executables with instant startup and efficiency. Enter Spring.
Spring Cloud Function favors using the functional programming paradigm to implement your business logic and provides useful features to build data pipelines, including type conversion and function composition. Functions can be exposed through different options (like web endpoints or message channels), and adapters are available to run them on platforms like Knative, AWS Lambda, Azure Functions, and GCP Functions. Spring Cloud Stream integrates your functions with messaging systems like RabbitMQ and Kafka without requiring any change to your code. Finally, Spring Native lets you compile your applications as native executable using GraalVM and providing instant startup, instant peak performance, and reduced memory consumption.
Not too long ago, a reactive variant of the JDBC API was released, known as Reactive Relational Database Connectivity (R2DBC). While R2DBC started as an experiment to enable the integration of SQL databases into systems that use reactive programming models, it now specifies a robust specification that can be implemented to manage data in a fully-reactive and completely non-blocking fashion.
In this session, we’ll briefly go over the fundamentals that make R2DBC so powerful. Then we’ll take a pragmatic look at the recently released R2DBC driver from MariaDB to shed some light on how you can take advantage of crucial concepts, like event-driven behavior and back pressure, that enable fully-reactive, non-blocking interactions with relational databases.
Saturday, June 26, 2021
picoCLI is a small library that can be used to create JVM based command line interface applications.
Within 30 minutes, we’ll look at how to setup a project, create a small application and package it for others to use.
picoCLI is nice for several reasons : CLIs are a great way to automate some commands we run every day. And because it supports Java and Kotlin, we can keep using our main language of choice rather than having to dive into bash or node. Finally, pico applications can be turned into native images using GraalVM, which allows for a nice end-user experience.
This talk is a third introduction to the topic, a third live-coding in the IDE, and a third best practices when creating CLI applications, especially in Java or Kotlin.
By the end of this talk, you’ll have a basic knowledge of what picoCLI can do, how to set it up, and should have ideas of use cases to run it with!
Runtime code generation is widely used by many state-of-the-art Java frameworks for implementing POJO-centric APIs, but it also opens the door to assembling more modular applications. This presentation offers an introduction to runtime code generation and its use on the Java platform. Furthermore, it discusses the upsides and downsides of several code generation libraries such as ASM, Javassist, cglib, and Byte Buddy.
In this talk, I talk about Java instrumentations and my recent work with Byte Buddy and how to apply code instrumentation. An older version of the talk can be found here: https://www.youtube.com/watch?v=80wCytGEY1g&t=2639s
Java, or JVM, has well-deserved fame as a hardware-unfriendly platform, and thus nobody sane will build database system or solutions where "mechanical sympathy" is crucial. using Java, except Apache Kafka, Elastic, Cassandra and Neo4j ;) ).
Garbage collector, speculating JIT, lack of control over "object layout", terrible support (mainly due to lack of abstraction) for functions of modern processors and operating systems.
And also JNI (who was there, I know what I'm talking about). Complex, slow, no major update since the day of release. Project Panama promises to change it. Simple, fast, safe. This talk will take a look at the state of Project Panama, focusing mainly on the foreign linker, our new interface to C world. Of course, you can expect running examples, core dumps, segfaults and other fancy things.
I will focus on two examples calling C code (from POSIX spec) from Java, and calling Java code from C. We will also touch on the topic of foreign memory as these to specs are tightly coupled together.