Is there a Log4j2 vulnerability with Spring Boot?

Java is both a compiled and interpreted language. While the javac tool takes the source code .java files you writes and compiles them to bytecode .class files, the JVM interprets this bytecode to produce machine code. This machine code is then fed to the CPU to ultimately process or run your program.

To maximize performance, Java utilizes a just-in-time (JIT) compiler to dynamically compile bytecode to machine code.  This JIT compiler is baked into the JVM and works automatically without any developer intervention.

While developers rarely need to concern themselves with the inner workings of this JIT, it's beneficial to understand what's happening under the hood.  This starts with understanding the difference between compiled vs interpreted languages..

Preface: Compiled vs Interpreted Languages

Languages like C and C++ are compiled languages.  These languages compile source code into an executable binary file that runs directly on the processor (CPU).

Compiled languages are good because they don't require any overhead during runtime.  Unlike an interpreted language, compiled code doesn't need to be evaluated at runtime.  This makes compiled languages generally faster than interpreted languages.

Compiled languages can be bad because they lack portability.  The compiled binary output is often specific to a certain architecture or platform.  The compiled output of your program may work on this machine but not that machine etc.

Compiled languages are also slower on startup and during testing.  This is because they need to be compiled first!

Languages like php, Python, and JavaScript are interpreted languages.  These languages rely on a separate program (the interpreter) to "interpret" the code during runtime.

Instead of compiling the source code upfront, interpreted languages read source code line by line, generating the binary instructions through the interpreter itself.  This makes it possible for interpreted languages to be "platform agnostic" meaning they can run on different platforms the same way.

Interpreted languages are good because they are portable.  You can download php for Mac, Windows, etc and your program will execute the same way.

Interpreted languages are bad because they take longer to execute code.  Unlike a compiled language, interpreters can't feed compiled code directly to a processor.  They have to "interpret" the source code line by line.

Interpreted languages make for faster startup times.  You don't have to wait for the compile step when your program starts.

The JIT compiler allows Java to be both a compiled and interpreted language.  It combines the performance advantage of a compiled language with the flexibility of an interpreted language.

When your Java program executes, the JVM interprets bytecode as part of code analysis and optimization.  It then uses this analysis to dynamically compile and store frequently reused methods to avoid interpreting the same bytecode over and over.

What does this JIT compiler look like?  Where does it live? How does it work?

The JIT compiler is part of the JVM that continuously runs to optimize performance.  While the JVM interprets bytecode, the JIT analyses execution and dynamically compiles frequently executed bytecode to machine code.  This prevents the JVM from having to interpret the same bytecode over and over.

The JIT compiler is not some separate application you download and run alongside your program.  It is simply a description of functionality that exists within the JVM.

The source code you write (.java) is compiled by javac to bytecode. When your program executes, the JVM starts interpreting this bytecode.

The interpreter translates the bytecode into machine code and feeds it to the CPU for processing.  While this happens, the JIT profiles and analyses the code execution.  It tracks the most frequently called methods and dynamically compiles these to machine code at runtime.

This dynamic process prevents the interpreter from having to "interpret" the same methods over and over.  Instead of having to translate bytecode to machine code, the interpreter can instead leverage cached machine code instructions from memory.

This is what makes Java both a compiled and interpreted language.  While the JVM initially interprets code, the JIT compiler works to selectively compile frequently executed code "just in time".

This gives Java the advantage of interpreted languages (faster startup times, more portability) and compiled languages (faster execution, optimized performance).

Client Side, Server Side, and Tiered Compilers

Before Java 8, you could specify either client or server JIT compilers.  While client compilers were better suited for apps having fewer resources available, server compilers worked better for long running apps.

A client side application may be more sensitive to startup time and have fewer resources available for code optimizations and JIT overhead.   A server side application may be long running and more appropriate for heavier optimizations and longer compile times.

The key difference between the two is the level of optimization and profiling. While profiling allows the JIT to better optimize the machine code it sends to the processor, it comes with a performance cost. Client side compilers minimize profiling to reduce overhead and startup time whereas server side compilers rely more heavily on profiling and optimizations.

Beginning with Java 8, the JVM takes a "tiered approach" where both client side and server side techniques are used.  During execution, the JVM initially interprets the bytecode.  It tracks frequently used methods and optimizes code based on the client side (C1) approach.  The JIT continuously analyzes execution and migrates to more of a server side (C2) approach for additional optimizations.

While modern Java installs utilize the tiered approach of combining C1 and C2 compilers, the C2 compiler is dated and hard to maintain.  For these reasons, the Graal JIT compiler was developed as part of a larger GraalVm project.

The Graal JIT compiler is written in Java, giving it the advantage of IDE integration, exception handling, and integration with profilers and debuggers.

The Graal JIT compiler also allows ahead of time (AOT) compiling where execution code is compiled upfront.  This reduces startup time experienced with the conventional JIT compiler.

There is a popular misconception that you can "download" a JIT compiler for Java.  While older versions allowed you to install a JIT as a plugin, all standard Java installations include the JIT compiler as part of the JVM.

As the JIT dynamically compiles code to machine language, it also performs optimizations on your source code to maximize performance.  Following are some examples of these optimizations:

The JIT compiler will optimize the original myMethod() through several steps...

Notice how the get() method is replaced with directly accessing the value. This eliminates method invocations and improves efficiency.

By setting z = a, the compiler reduces the latencies of accessing b.value to improve performance.

Notice how this optimization removes unnecessary variables. Since z ultimately just equals a the JIT compiler removes it altogether.

Since a = a is redundant, the JIT compiler simply removes this "dead code" during optimization.

Apart from these steps, JIT compiler also includes other optimizations like:

Let's say you have a basic null check like:

If JIT notices myVar is never called with null then it will remove this code altogether.

Let's say you have an if..else branch like this:

If the JIT compiler notices that x < y more often than not, it will reverse the branch...

If you have a nested loop, the JIT compiler will unroll it to minimize assembly jumps..

The JIT Compiler in Java including what is the JIT compiler, how the JIT compiler works, JIT compiler optimizations and more.

The JIT Compiler in Java

Java Heap vs Stack?

i still prefer the Promise myself.  It's just easier to understand and work with (and native to JavaScript at this point).

When you say something like "An Observable can do everything a Promise can but not the other way around"....you should be saying "both can be used to achieve the same async activity in JavaScript

The Promise is still relevant and great for async operations where you are only concerned with the result of one async operation.  While the observable handles this well with Angular, it's still perfectly reasonable to use the Promise library for http requests, etc.

stackchief

Quickly understand JavaScript observables.  Implement the Observable class from scratch and understand what makes observables different from promises.

JavaScript Observables in 5 Minutes

The difference between heap and stack is how the memory is used.

Heap memory is used to store objects you create when your program executes.  It exists as long as your application is running.

Stack memory is used to store primitive data types and references (to things stored in the heap) when your program executes.  It is thread specific.

Blocks of memory are added and removed from the stack as your program executes.  They are created in a LIFO (last in first out) fashion when a method is invoked.  They are released when the method has finished execution.

I'm a novice Java developer and just getting my feet wet with memory management.  Can someone explain heap vs stack and how these work?

What is the difference between heap and stack

What is the difference between heap and stack?

Software Engineer Salary?

You should ALWAYS use SimpleChanges with these lifecycle hooks...

i think the way Angular handles change events is much simpler than ReactJS.  While these ngonchange examples may seem a bit overboard for JavaScript, it's still easier to understand these life cycle hooks than functional components in React (in my opinion).

Does anyone know what is more performant when it comes to things like React hooks (useEffect, useState) etc and things like ngOnChanges???

Steve Jennings

People often get confused when they see ngOnChanges fire before ngOnInit. At a high level you would assume ngOnInit is the first thing called when a component is rendered.

This post does a good job of emphasizing the fact that ngOnChanges is linked to children components and their bound @Input properties.  When you initialize a child component from a parent, you are setting the component's @Input properties as part of the component's initialization....

A child component's @Input properties are updated even before the component is initialized...

Alexander Joseph

hoopmiester

ngOnChanges example for Angular including latest version example with explanation

ngOnChanges Example | Angular

this post does a really good job of explaining how ngOnChanges() works with parent components.

You have to remember that the parent inputs will always invoke ngOnChanges() from the child...

ngOnChanges() == useEffect() in React???

The JRE runs the JVM.  The JVM runs your Java application.  You build your Java application with the JDK.

Well. My company standard it's openJDK 8 since 2019... Cheers!

juanrios.com@localhost

thank you, I finally realize that Java 8 is the most popular version.

Evgeny Ivanov

A discussion surrounding the different versions of Java including the difference between SE and EE as well as key features of Java 7, 8, and 9.

Which Version of Java Should You Use?

Kafka consumers are not thread safe. For these reasons, most people rely on the ConcurrentMessageListenerContainer to create a multi-threaded environment for consuming messages.

When you use something like @KafkaListener it's utilizing the ConcurrentMessageListenerContainer automatically as the default container factory.

I understand how both classes can be used to implement Kafka listeners in Spring Boot but when should you use one over the other??? Any help appreciated!

KafkaMessageListenerContainer vs ConcurrentMessageListenerContainer

FewerLinesThanYou

Is there a Log4j2 vulnerability with Spring Boot?

The JIT Compiler in Java

Java Heap vs Stack?

Software Engineer Salary?