Programming languages are classified based on their levels of abstraction. Java is a high-level language, so it needs to be translated to native code for execution. This can be achieved by either compilation or interpretation. However, the JVM seeks to take advantage of both.
‍
The javac command-line tool compiles Java source code into Java class files containing platform-neutral bytecode, not native executable code. To better understand how the JVM executes bytecode, we will need to take a deeper look into its architecture.
‍
The JVM was designed with portability in mind. Thus, it initially uses an interpreter to execute all bytecode. The JIT compiler kicks-in later to boost performance. It compiles bytecode to native code for repeated method calls. In this talk we will explore the two different JIT compilers used by the JVM. We will explain the tiered compilation concept and its five compilation levels.
‍
At the end of this lecture, you will be able to explain how a combination of an interpreter and a JIT compiler enables both high performance and platform-neutral execution of your Java code.

Have you ever worked on a legacy project, like lots of source code, but no unit tests? Or no continuous delivery? Static code analysis completely missing, or even a simple code standard totally absent?

Projects like these are still more often the case than we like to think. In fact, maybe you are a developer stuck in such a project, even though you have tried to raise these issues as problems? Were you told that is gold-plating, or simply too much work to fix?

I would like to share my experiences from a couple of such projects, both from the perspective of a tech lead in a project like this, and as a software reviewer (i.e. doing software auditing). But most important: I would like to help you with some good arguments, to convince your project leader why these things matter.

We keep hearing how amazing it is to cut a giant monolith into microservices, but we rarely hear how to get started when knowing little about the subject. In this talk, I will take you through the journey of planning your migration to microservices from zero. I will show you how to bootstrap a new project covering things like security, observability, graceful shutdown, and grpc. The best thing about it? You don't need to know anything to jump on the train!

Serverless architecture is exactly the opposite of a monolith architecture, small services (or functions) running in a constrained running environment (limited access to CPU and memory). Furthermore, as we move to a model where we pay per usage, the services might need to go from 0 to infinite instances in a matter of milliseconds to start serving requests. Because of these constraints, we have now seen a number of developers at many organizations considering moving to Node.js or Golang to get the performance and tiny memory footprint they need to run in a serverless environment.

‍

Startup times of containers are becoming increasingly important with elastic scaling in the cloud - nobody wants to wait 2 minutes for a new instance of the service to appear. This is where the shooting star of java-based microservices, Spring Boot, fails to shine.

Due to the system, the startup time of the container increases with the amount of classes on the classpath. Also, the memory consumption of a Spring Boot application is not really low.

Micronaut, developed by the creators of the Grails framework, claims to solve these problems. In this talk, we take a look at how Microservices can be developed with Micronaut and see if it keeps its promises.

Bonus: Since Micronaut barely uses Reflection, it should be possible to compile it into a native image using the GraalVM AOT compiler. In this talk we will also try this out and measure the performance of this native image.