Nicolas Frankel

Java has been my bread and butter for almost two decades. Several years ago, I started to learn Kotlin; I never regretted it.

Though Kotlin compiles to JVM bytecode, I sometimes have to write Java again. Every time I do, I cannot stop pondering why my code doesn’t look as nice as in Kotlin. I miss some features that would improve my code’s readability, expressiveness, and maintainability.

This talk is not meant to bash Java but to list some features I’d like to find in Java.

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind.

Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible.

In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

https://blog.frankel.ch/end-to-end-tracing-opentelemetry/

Python is ubiquitous in scripts, and it has definite benefits. However, Kotlin developers don't need to migrate to another stack to create scripts.

In this talk, I'll show you how I use Kotlin to have an always up-to-date GitHub profile.

Builds require a few properties, chief among them reproducibility. I would consider speed to be low on the order of priorities. However, it’s also one of the most limiting factors to your release cycle: if your build takes T, you cannot release faster than each T. Hence, you’ll probably want to speed up your builds after you’ve reached a certain maturity level to enable more frequent releases.

I want to detail some techniques you can leverage to make your Maven builds faster.

In this talk, I’ll demo how you can migrate a traditional sample Spring Boot application written in Kotlin to coroutines one step at a time via a hands-on demo.

From Wikipedia, Reactive Programming is 'a declarative programming paradigm concerned with data streams and the propagation of change.'

The programming model is complex to master. It requires a lot of experience to feel comfortable with it. However, there’s no denying that it fits the cloud ecosystem perfectly. Since on-premises infrastructure is oversized, running a program that executes a couple of additional CPU cycles won’t change anything. On the other hand, you will pay for them if you host the same program on third-party infrastructure. Depending on the number of those cycles, and the number of nodes the program runs on, it can make a huge difference in your monthly bill.

In this talk, I’ll demo how you can migrate a traditional sample Spring Boot application written in Kotlin to coroutines one step at a time via a hands-on demo.

While a plain Dockerfile gets the job done, there are actually many more ways to containerize your Java app. They come with a couple of pros, and some cons.

As “the Cloud” becomes more and more widespread, now is a good time to assess how you can containerize your Java application. I assume you’re able to write a a Dockerfile around the generated JAR. However, each time the application’s code will change, the whole image will need to be rebuilt. If you’re deploying to a local Kubernetes cluster environment, this increases that much the length of the feedback loop.

In this demo-based talk, I’ll present different ways to get your Java app in a container: Dockerfile, Jib, and Cloud Native Buildpacks. We will also have a look at what kind of Docker image they generate, how they layer the images, whether those images are compatible with skaffold, etc.

Kotlin is one of those “new” JVM languages that are currently rocking the boat. Although it’s made a great impact on Android, it’s equally good on the server side. As Domain-Specific Languages are constrained by the language they run on, Kotlin frees developers from Java fluent builders to propose something better.

Using the Vaadin web framework as an example, I’ll demo how one could design its own DSL with Kotlin.

Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to an unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided.

Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run… By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.