Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
1. Overview
The Java Virtual Machine (JVM) is an abstract computing machine that enables a computer to run Java programs. The JVM is responsible for executing the instructions contained in the compiled Java code. To do so, it requires a certain amount of memory to store the data and instructions it needs to operate. This memory is divided into various areas.
In this tutorial, we’ll discuss the different types of runtime data areas and their purpose. Every JVM implementation must follow the specifications explained here.
2. Shared Data Areas
The JVM has several shared data areas that are shared amongst all threads running in the JVM. As a consequence, various threads can simultaneously access any of these areas.
2.1. Heap
The Heap is the runtime data area where all Java objects are stored. Thus, whenever we create a new class instance or array, the JVM will find some available memory in the Heap and assign it to the object. The Heap’s creation occurs at the JVM start-up, and its destruction happens at the exit.
As per the specification, an automatic management tool must handle the storage of the objects: this tool is known as the garbage collector.
There is no constraint about the Heap size in the JVM specifications. Memory handling is also left over to the JVM implementations. Nevertheless, if the garbage collector cannot reclaim enough free space to create a new object, the JVM throws an OutOfMemory error.
2.2. Method Area
The Method Area is a shared data area in the JVM that stores class and interface definitions. It is created when the JVM starts, and it is destroyed only when the JVM exits.
Concretely, the class loader loads the bytecode of the class and passes it to the JVM. The JVM then creates an internal representation of the class, which is used to create objects and invoke methods at runtime. This internal representation gathers information about the fields, methods, and constructors of the classes and interfaces.
Additionally, let’s point out that the Method Area is a logical concept. As a result, it may be part of the Heap in a concrete JVM implementation.
Once more, the JVM specifications don’t define the size of the Method Area, nor does it define the way the JVM handles memory blocks.
If the available space in the Method Area is not enough to load a new class, the JVM throws an OutOfMemory error.
2.3. Run-Time Constant Pool
The Run-Time Constant Pool is an area within the Method Area that contains symbolic references to the class and interface names, field names, and method names.
The JVM takes advantage of the creation of the representation for a class or interface in the Method Area to simultaneously create the Run-Time Constant Pool for this class.
When creating a Runtime Constant Pool, if the JVM needs more memory than is available in the Method Area, an OutOfMemory error is thrown.
3. Per-thread Data Areas
In addition to the shared runtime data areas, the JVM also uses per-thread data areas to store specific data for each thread. The JVM indeed supports many threads executions at the same time.
3.1. PC Register
Each JVM thread has its PC (program counter) register. Each thread executes the code of a single method at any given time. The behavior of the PC depends on the nature of the method:
- For a non-native method, the PC register stores the address of the current instruction being executed
- For a native method, the PC register has an undefined value
Lastly, let’s note that the PC register lifecycle is the same as the one of its underlying thread.
3.2. JVM Stack
Similarly, each JVM thread has its private Stack. The JVM Stack is a data structure that stores method invocation information. Each method call triggers the creation of a new frame on the stack to store the method’s local variables and the return address. Those frames can be stored in the Heap.
Thanks to the JVM Stack, the JVM can keep track of the execution of a program and log the stack trace on demand.
Once again, the JVM specification lets the JVM implementations decide how they want to handle the JVM Stack’s size and memory allocation.
A memory allocation error on the JVM Stack entails a StackOverflow error. However, if a JVM implementation allows the dynamic extension of its JVM Stack’s size, and if a memory error occurs during the extension, the JVM has to throw an OutOfMemory error.
3.3. Native Method Stack
A native method is a method written in another programming language than Java. These methods aren’t compiled to bytecode, hence the need for a different memory area.
The Native Method Stack is very similar to the JVM Stack but is only dedicated to native methods.
The purpose of the Native Method Stack is to keep track of the execution of a native method.
The JVM implementation can decide on its own the size of the Native Method Stack and how it handles memory blocks.
As for the JVM Stack, a memory allocation error on the Native Method Stack leads to a StackOverflow error. On the other hand, a failed attempt to increase the Native Method Stack’s size leads to an OutOfMemory error.
To conclude, let’s note that the specification highlights that a JVM implementation could decide not to support native method calls: such an implementation wouldn’t need to implement a Native Method Stack.
4. Conclusion
In this tutorial, we’ve elaborated on the different types of runtime data areas and their purpose. These areas are crucial for the proper functioning of the JVM. Understanding them can help optimize the performance of Java applications.
