DEV Community: Aleksandr Tiurin

Project Valhalla: Fundamental Changes in the JVM

Aleksandr Tiurin — Tue, 03 Feb 2026 14:03:02 +0000

In my 12 years of Java development in fintech, I have not seen a project that promises such a radical improvement in solving our everyday problems. We, programmer, spend thousands of person-hours optimizing code, but everything ultimately runs into a fundamental limitation of Java: the cost of objects. Valhalla is a direct response to this pain. In this article, I will break down how it will change the way we process data, using an example that may be familiar to many of us — XML parsing.

Is Valhalla a Practical Lifesaver for Data-Intensive Code?

Every OpenJDK project addresses a systemic problem. Valhalla is the answer to an architectural contradiction we have tolerated for decades: to get type safety and abstractions, we are forced to pay in memory and CPU time by creating objects for every chunk of data. In large systems, where 80% of the workload is transforming and validating streams of structured data, this price becomes unacceptable.

I sometimes have to work with parsing financial XML. Yes, XML is not as popular today, but it firmly occupies its niches — for example, XHTML, SOAP, and various configurations (such as Tomcat, SoapUI, and others), as well as data import/export.

The Problem: Parsing Financial XML

Let’s take a typical scenario — parsing an account statement in ISO 20022 format (https://www.iso20022.org). One file contains thousands of transactions (Ntry). Each transaction is a cascade of objects:

<Ntry>
    <Amt Ccy="USD">1000.50</Amt>
    <CdtDbtInd>CRDT</CdtDbtInd>
    <Sts>BOOK</Sts>
    <BookgDt>
        <Dt>2026-01-01</Dt>
    </BookgDt>
    <ValDt>
        <Dt>2026-01-01</Dt>
    </ValDt>
  ...
</Ntry>

Traditional Java Model:

public class MonetaryAmount {
    private final BigDecimal value; // First problem
    private final Currency currency; // Second problem
}

public class Transaction {
    private List<EntryDetails> entryDetails;  // Third problem
    private MonetaryAmount amt;
    private LocalDate bookgDt; // LocalDate is being considered as a value class in future JDK versions!
    // + other fields
}

What’s wrong here from a performance perspective:

BigDecimal is a performance killer — internally it uses an int[] array, which is a separate object with its own header
Currency is redundant: Most of the time it’s a constant from a pool, but we still store a reference to it
Cascading allocations: One Transaction > 3–5 new heap objects
Memory fragmentation: MonetaryAmount objects are scattered across the heap, destroying locality

When processing 100K transactions, 300–500 thousand temporary objects are created. The GC is pushed to its limits, and the CPU idles, waiting for cache misses while walking this reference graph.

Value Types in Action

As stated in JEP 401, the project gives developers the ability to explicitly choose which objects need identity and which do not. Value classes are that choice: object semantics with primitive-like storage and performance.

Let’s move to a Valhalla-based model:

// Value class for monetary amounts
public value class MonetaryAmount {
    private final long value;   // Primitive instead of BigDecimal
    private final String currency; // String remains a reference type

    public MonetaryAmount(String valueStr, String currency) {
        this.value = parseToMinorUnits(valueStr);
        this.currency = currency;
    }
}

public class Transaction {
    private final MonetaryAmount amt;     // Flattened embedding
    private final List<EntryDetails> ntryDtls;
}

Critical change: MonetaryAmount can now be flattened by the JVM into the memory layout of Transaction, eliminating an extra level of indirection wherever possible.

What This Means at the CPU and Memory Level

Before (Classic Java):

Transaction[] array:
[ref1, ref2, ...]
 |       |       
 \       \       
[Object1][Object2]...
 In each object:
 [header][refToAmount][refToDetails]
          |             |           
          \             \           
     [BigDecimal]  [ArrayList]

After (With Valhalla):

Transaction[] array (flat representation):
[header1][amount1.value][amount1.currency][refToDetails1]
[header2][amount2.value][amount2.currency][refToDetails2]
...

A value object has no identity. It does not have its own unique memory address like an entity. For a parser, this yields measurable advantages:

60–70% fewer allocations: Instead of 5 objects per transaction — 1–2
3–5× better data locality: All transaction fields are stored sequentially
An order-of-magnitude reduction in GC pressure: Fewer objects → shorter and rarer pauses
40% faster iteration: The CPU gets all fields in a single cache line fetch

Let’s Build a Practical Benchmark (Prototype on a Valhalla EA Build)

@Benchmark
@BenchmarkMode(Mode.Throughput)
public List<Transaction> parseWithValhalla(Blackhole bh) {
    return parseXml(FINANCIAL_XML_LARGE); // Returns List<Transaction> with value classes
}

@Benchmark  
@BenchmarkMode(Mode.Throughput)
public List<TransactionLegacy> parseLegacy(Blackhole bh) {
    return parseXmlLegacy(FINANCIAL_XML_LARGE); // Classic objects
}

Why XML Parsing Benefits So Much From This Approach

The “read–validate–accumulate” pattern maps perfectly to value types. A StAX parser creates objects sequentially — exactly where flattening delivers maximum impact.
Immutability by default is already standard practice in financial models. Value classes simply formalize this at the JVM level.
Reducing GC pressure is critical for near-real-time systems. Parsing a 100 MB XML file will no longer trigger 5-second garbage collection pauses.
Post-processing becomes faster: Once parsing is done and we start aggregating, filtering, and calculating — the data is already tightly packed, with no pointer chasing.
Lower memory usage becomes an architectural effect: By eliminating object headers and cascading allocations, the expected heap footprint is reduced by more than 2× compared to the classic object model.

My Experiment: A StAX Parser With Valhalla

Goal: Validate the hypothesis that switching financial models to value classes provides:

>50% fewer allocations
>30% faster full pipeline (parsing + aggregation)
Elimination of Young GC pauses for files >100 MB

Stack:

Valhalla early-access build (latest)
Standard StAX (javax.xml.stream)
JMH for benchmarking
Real test data from a sandbox environment (sanctioned)

Key Experimental Code:

// Value version of MonetaryAmount
public value class MonetaryAmount {
    private final long value; // Stored in minor units (cents)
    private final String currency;
}

Preliminary Observations (Prototype):

Replacing BigDecimal with long for minor units is the single most impactful optimization
Nested value types (Amount inside Transaction) work as expected
Compatibility with existing code: value classes can be used wherever an interface or class was expected

What Will Need to Change in Real Projects?

After practical testing of Valhalla on one of our XML parsing projects, achieving similar performance gains in other parts of the system will require some preparation:

Identify value candidates in your models: Look for immutable DTOs that are currently classic objects — Amount, Rate, Coordinate, Range
Rethink object pools: Many pools (ObjectPool<Transaction>) become unnecessary — value types can be created “on the stack” without GC pressure
Prepare your libraries: Verify that the libraries you use (Jackson for JSON, JAXB for XML) are ready to work with value classes. Oracle has already announced support in the Jakarta EE stack
Rewrite native optimizations: Code with byte[] buffers and manual serialization can be replaced with clean value types at the same performance level

Real-World Use Cases

After successfully accelerating a StAX parser, I realized that much more of the project can be migrated to Valhalla. Here are some examples of what that might look like.

1. High-Frequency Market Data Parsing (FIX/FAST, XML)

// Today
public class MarketDataEvent {
    private final BigDecimal price;
    private final BigDecimal size;
    private final long timestamp;
}

// With Valhalla  
public value class Price {
    private final double mantissa;
    private final int exponent; // Decimal support via integers
}

public value class MarketDataEvent {
    private final Price price;
    private final Price size;
    private final long timestamp;
}
// Array of 1,000,000 events: previously 24 bytes of headers per event,
// now 0 bytes of headers for the value portion

2. Payment Validation With Transformation Chains

value class ValidatedAmount {
    private final double value;
    private final String currency;
    private final boolean isValid;

    public ValidatedAmount convert(String targetCurrency) {
        double rate = getRate(this.currency, targetCurrency);
        return new ValidatedAmount(this.value * rate, targetCurrency, this.isValid);
    }
}
// Each convert() call creates no heap objects!

3. Caching Frequently Used Keys

public value class CurrencyPair {
    private final String base;
    private final String quote;
}

// Instead of 2 objects per key (String + String) + CurrencyPair header
// You get flat storage of characters inside the HashMap.Node block
// The JVM can store value keys without separate heap allocation

Of course, not every class should become a value type. Entities with identity, stateful objects, and cache entries with TTL should remain classic classes.

Conclusion

Valhalla is not “just another language feature.” It’s about finally being able to write expressive domain models without compromising on performance.

For developers, this means:

The end of the era of object pools and manual serialization for optimization
The ability to use clean DDD models in high-throughput systems
Lower system TCO through reduced memory and GC requirements
Java becoming competitive with C++ and Rust in data processing, while retaining the full power of the JVM ecosystem

My verdict after experimenting with EA builds: The technology works. The impact is visible even today. By the time it reaches production, we’ll have a solid set of patterns and libraries ready to unlock its benefits immediately. The final release will take time, but understanding these changes now is an investment in tomorrow.

My repository with the experiment: GitLab: StAX Valhalla

Where to Track Progress

JEP 401: Value Classes — the foundation
Valhalla Early-Access Builds — try it today
Inside.java Newscast — weekly updates

If you’re not familiar with Valhalla, now is the perfect time to start experimenting. The project is actively evolving. As of today, early-access builds with value class support are available (as listed on the project page).

To get started:

Download the Early-Access (EA) build from the Valhalla project page (https://openjdk.org/projects/valhalla)
Enable preview features when compiling and running:

javac --enable-preview --source 24 Complex.java
java --enable-preview Complex

No Magic: How Spring, Lombok, and Mockito Actually Work Under the JVM Hood

Aleksandr Tiurin — Mon, 13 Oct 2025 19:44:18 +0000

Introduction: It’s Not Reflection—It’s Bytecode

I’ve been developing in Java for several years—from small utilities to high-load services in distributed systems. In such systems, even a few seconds of downtime are unacceptable: we’re talking about SLAs of 99.99% and higher. To guarantee this level of reliability, I’ve had to do more than just write code—I’ve needed to deeply understand how it actually works inside the JVM.

This led me to load testing, memory dump analysis, and profiling using agents like Async-Profiler and OpenTelemetry—and ultimately to the question: “How does Spring inject transactions without my involvement? Why can Mockito mock a class with no constructor? And how does Lombok ‘add’ methods that don’t exist in the source code?”

I used to think it was magic too. But after diving into the architecture of the Java Virtual Machine (JVM), I realized everything is far more logical than it appears. In this article, we’ll walk step by step through how the JVM loads classes, verifies their correctness, and how you can modify their behavior at runtime.

We’ll explore the full lifecycle of a class—from loading into the JVM to bytecode manipulation. We’ll understand how Class Loading works, why verification is necessary, and how tools like ASM, Byte Buddy, and Javassist enable us to move from passive code consumption to active transformation. We’ll also examine how Lombok, Mockito, and Spring AOP leverage these mechanisms—without any magic at all.

1. Class Loading: Delegation, Isolation, Customization

The process of loading a class into the JVM begins long before the first bytecode instruction is executed. This process, known as Class Loading, is one of the earliest stages in a class’s lifecycle. The key component of this system is java.lang.ClassLoader, an abstract class responsible for locating and loading the binary representation of a class (in .class format) and converting it into an instance of java.lang.Class.

The central principle of the ClassLoader architecture is the delegation model. When a ClassLoader instance receives a request to load a class by name, it first delegates the request to its parent ClassLoader. Only if the parent cannot locate the class does the current ClassLoader attempt to load it itself. This hierarchy ensures security and prevents substitution of core system classes.

The traditional hierarchy consists of three levels:

Bootstrap ClassLoader (Primordial ClassLoader): sits at the top of the hierarchy and is part of the JVM itself. Implemented in native code (C/C++), it loads the most fundamental Java platform classes—those found in rt.jar (or in modules starting with Java 9+), such as java.lang.Object, java.lang.String, and others. It cannot be directly accessed from user code.
Platform ClassLoader (formerly Extension ClassLoader): introduced in Java 9+, it loads classes from platform modules. Prior to Java 9, this role belonged to the Extension ClassLoader, which loaded JAR files from the extension directory (jre/lib/ext).
System ClassLoader (Application ClassLoader): this is the default ClassLoader for applications. It loads classes from paths specified in the CLASSPATH environment variable, the -classpath command-line argument, or the default directory. This is the ClassLoader used to load the application’s main class specified in the java command.

Developers can extend this model by creating custom ClassLoader implementations. This is typically done by subclassing ClassLoader and overriding one of its methods. The most common approach is to override the findClass(String name) method. This preserves the standard delegation model (implemented in loadClass(String name)) while allowing customization of how the class’s byte representation is located and retrieved.

The loadClass(String name) method serves as the entry point for class loading. It implements the delegation algorithm: first checking if the class has already been loaded (caching), then delegating to the parent, and only calling findClass(name) if the class remains unfound. The defineClass(byte[] b, int off, int len) method is a protected utility that actually converts a byte array into a Class instance. It must be invoked from within findClass or loadClass after the bytes have been obtained. Importantly, defineClass does not validate the bytecode—that responsibility falls to the subsequent linking phase.

Creating custom ClassLoaders has many practical applications but also carries risks. Poor implementations can lead to memory leaks. Additionally, each new ClassLoader creates an isolated namespace for classes, which may result in ClassNotFoundException or NoClassDefFoundError if dependencies aren’t properly resolved. Thus, working with ClassLoaders demands not only technical knowledge but also a deep understanding of application architecture.

The idea of dynamically generating classes—once considered a niche technique—is now becoming part of the platform itself. The Unnamed Classes feature introduced in the recently released Java 25 allows running Java script files (.jsh), which are compiled on-the-fly into anonymous classes and loaded by the system ClassLoader via the defineClass mechanism. This transforms what was once an advanced, specialized approach into a mainstream execution path for specific use cases.

2. Linking Phase: Verification, Preparation, Resolution

After the ClassLoader successfully loads the binary data of a class and creates an instance of java.lang.Class, the class does not immediately become executable. Before its methods can be invoked or its fields accessed, the class must undergo the linking process. This multi-stage procedure—defined in the JVM specification (JLS §5.4)—consists of three sequential phases: Verification, Preparation, and Resolution. These steps are critical for ensuring the stability, security, and integrity of the Java runtime environment.

Verification: The Guardian of JVM Integrity

Verification is the most complex and crucial phase of linking. Its purpose is to ensure that the class is safe and does not violate JVM invariants. It checks the structure of the .class file, type safety, operand stack balance, correctness of references, and access control.

The verification process is performed by internal JVM components such as ClassFileParser and includes several levels of analysis:

Structural Verification – validates the format of the .class file, version numbers, constant pool size, etc.
Bytecode Verification – analyzes the bytecode stream of each method.

Starting with Java 7, bytecode verification was significantly optimized through stack map frames—metadata inserted by the compiler into the Code attribute that explicitly describes the types of local variables and the operand stack at key points in the code. This allows the verifier to perform a single-pass check, greatly accelerating application startup.

Here is an example of invalid bytecode that would fail verification:

aload_0           // Push 'this' (an object reference) onto the stack
iconst_0          // Push int 0 onto the stack
invokevirtual java/io/PrintStream.println:(Ljava/lang/String;)V

This code attempts to call println(String) with an int argument, violating the method’s signature. The verifier will detect the type mismatch on the operand stack and throw a java.lang.VerifyError.

Preparation: Memory Allocation for Static Members

During the Preparation phase, the JVM allocates memory for all static fields of the class. At this stage, fields are initialized only to their default values (0 for numeric types, false for boolean, null for reference types). Initializers like static int x = 5; are executed later—in the <clinit> method (the static initializer).

This phase also includes setting up internal JVM data structures used to represent the class, such as virtual method tables (vtables) and interface method tables (itables).

Resolution: Resolving Symbolic References

In this phase, the JVM converts symbolic references from the constant pool (class names, method names, field names) into direct references to actual runtime entities in memory. Resolution is typically performed lazily—upon the first use of a reference.

The main types of resolvable references include:

Classes and interfaces – loaded by name;
Fields – located and access-checked;
Methods – resolved by name and descriptor, with checks for overriding validity and accessibility.

If any error occurs during resolution—for example, a class is missing, a method doesn’t exist, or access rules are violated—the JVM throws an appropriate error: NoClassDefFoundError, NoSuchFieldError, NoSuchMethodError, IllegalAccessError, etc.

Once linking completes successfully, the class is technically ready for use—but its static initialization (<clinit>) is deferred until the first active use of the class.

3. Bytecode and Class File Format: The Structure of .class

Understanding class loading and linking is impossible without a deep dive into the very entity they operate on—the .class file format. This binary format, strictly defined in the JVM Specification, serves as the universal carrier of compiled Java code. It is independent of the source language (Kotlin, Scala, Groovy also compile to this format) and the target platform’s architecture, enabling the famous "write once, run anywhere" paradigm. Examining its structure reveals exactly how the JVM interprets and verifies code.

ClassFile Structure

A .class file begins with the magic number 0xCAFEBABE, followed by version information, the constant pool, and class metadata:

ClassFile {
    u4 magic;
    u2 minor_version, major_version;
    cp_info constant_pool[...];
    u2 access_flags, this_class, super_class;
    u2 interfaces[...];
    field_info fields[...];
    method_info methods[...];
    attribute_info attributes[...];
}

Key components:

minor_version, major_version: define the file format version. For example, major_version=52 corresponds to Java 8. The JVM will refuse to load classes with a higher version.
constant_pool: the central repository for class names, method names, strings, and type descriptors. All other structures reference it by index.
fields, methods: described by name, descriptor, and attributes.
attributes: optional data sections. The most important include:
- Code: contains the method’s bytecode, max stack size, local variable count, and exception handling table.
- LineNumberTable / LocalVariableTable: used for debugging.
- RuntimeVisibleAnnotations: stores annotations accessible via reflection.

Bytecode: The Language of a Stack Machine

Bytecode is a set of instructions executed by the Java Virtual Machine. The JVM is a stack-based machine, meaning most operations pass data through an operand stack rather than CPU registers.

Each instruction consists of a single byte (the opcode) and, optionally, operands. Consider this method:

public int add(int a, int b) {
    return a + b;
}

Its bytecode (as shown by javap -c):

  Code:
     0: iload_1
     1: iload_2
     2: iadd
     3: ireturn

iload_1: loads the value from local variable index 1 (a) onto the operand stack.
iload_2: loads the value from local variable index 2 (b) onto the stack.
iadd: pops two int values from the stack, adds them, and pushes the result back.
ireturn: pops the int result from the stack and returns it.

This example shows how the high-level expression a + b is translated into a sequence of stack operations. During the linking phase, the verifier must ensure the operand stack is always in a consistent state—for instance, that exactly two int values are present before iadd executes.

Understanding the .class file structure and bytecode semantics is an absolute prerequisite for any code manipulation. Tools like ASM work directly with these low-level structures, reading and modifying byte streams in strict compliance with the format specification. Any intervention at this level requires full awareness of how changes will affect verification and subsequent execution.

Language evolution continuously shapes the .class format. For example, the introduction of Unnamed Variables (JEP 477) (var _ = ...) in Java 25 requires special handling by the compiler. Although the variable _ is unused, it must still appear in the LocalVariableTable attribute of the Code section—but with special flags indicating its "unnamed" status. This illustrates how even seemingly simple language features trigger changes in JVM’s low-level data structures, which must be correctly processed and verified.

4. Bytecode Manipulation: ASM, Byte Buddy, Javassist

In previous sections, we examined how the JVM consumes bytecode. Now it’s time to move to the next level—active creation and modification of this code. Bytecode manipulation is a powerful technique that allows programmatic alteration of class behavior before or during execution. This isn’t just “reflection on steroids”—it’s direct intervention into the essence of executable code. Specialized frameworks exist for this purpose, each offering its own level of abstraction and approach.

ASM: Low-Level Control

ASM is the most popular and performant bytecode manipulation framework. It operates at the lowest possible level, providing direct access to bytecode instructions and .class file structures. ASM uses the Visitor pattern, where ClassVisitor, MethodVisitor, and other components traverse class elements, allowing developers to insert, remove, or replace instructions.

ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES);
ClassVisitor cv = new MyClassVisitor(cw);

// When visiting the 'toString' method
@Override
public MethodVisitor visitMethod(int access, String name, String descriptor,
                                 String signature, String[] exceptions) {
    MethodVisitor mv = cv.visitMethod(access, name, descriptor, signature, exceptions);
    if ("toString".equals(name)) {
        return new AddLoggingAdviceAdapter(mv); // Insert logging
    }
    return mv;
}

// Adapter that adds code before and after the method
class AddLoggingAdviceAdapter extends AdviceAdapter {
    protected AddLoggingAdviceAdapter(MethodVisitor mv, int access, String name, String desc) {
        super(ASM9, mv, access, name, desc);
    }

    @Override
    protected void onMethodEnter() {
        mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
        mv.visitLdcInsn("Entering toString()");
        mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);
    }
}

Pros of ASM: Maximum flexibility and performance, minimal overhead.

Cons: Complex API, requires deep understanding of bytecode and stack map frames. A stack management error will cause a VerifyError.

Byte Buddy: A Modern DSL over ASM

Byte Buddy positions itself as a modern alternative to CGLIB and a more convenient wrapper over ASM. It provides a high-level, type-safe DSL that lets you describe transformations almost as if writing Java, hiding the complexities of bytecode manipulation.

new ByteBuddy()
  .redefine(User.class)
  .method(named("toString"))
  .intercept(Advice.to(LoggingInterceptor.class))
  .make()
  .load(getClass().getClassLoader(), ClassLoadingStrategy.Default.WRAPPER);

Where @Advice.OnMethodEnter in LoggingInterceptor is automatically converted into the corresponding bytecode instructions.

Pros of Byte Buddy: Clean, readable API; excellent support for new Java features (modules, records, sealed classes); powerful dynamic proxy capabilities.

Cons: Depends on ASM; some overhead due to abstractions.

Javassist: Source-Like Code Manipulation

Javassist (Java Programming Assistant) offers the highest level of abstraction. It allows developers to write modifications as strings of Java source code, which are then compiled into bytecode on the fly.

CtClass ctClass = ClassPool.getDefault().get("com.example.User");
CtMethod ctMethod = ctClass.getDeclaredMethod("toString");
ctMethod.insertBefore("{ System.out.println(\"Entering toString\"); }");
byte[] modifiedBytes = ctClass.toBytecode();

Pros of Javassist: Extremely easy to use, especially for quick PoCs.

Cons: Least performant, limited flexibility, may produce suboptimal bytecode. Not always compatible with the latest JVM versions.

Choosing the Right Tool

The choice depends on the task:

ASM: When maximum performance and full control are required (e.g., APM agents).
Byte Buddy: For most modern tasks, especially when support for new standards and code readability matter.
Javassist: For simple tasks or when rapid implementation is needed.

All these tools generate bytecode that must pass JVM verification. Their effectiveness lies in “knowing the rules” and correctly generating stack map frames to avoid VerifyError.

5. Runtime Instrumentation: java.lang.instrument and JVMTI

So far, we’ve treated bytecode manipulation as a process that precedes or coincides with class loading. However, the most powerful and flexible capabilities emerge when changes are applied at runtime, without restarting the application. This is achieved through two primary mechanisms: the high-level java.lang.instrument API and the low-level JNI-based JVMTI (JVM Tool Interface).

`java.lang.instrument`: Dynamic Transformation

The java.lang.instrument package, introduced in Java 5, provides a standard way for agents to attach to the JVM and modify bytecode on the fly. An agent is a special JAR file attached to the JVM either at startup or dynamically during execution.

Premain Agent (-javaagent):

An agent attached at JVM startup using the -javaagent:my-agent.jar flag. It must contain a public static void premain(String agentArgs, Instrumentation inst) method. At this stage, you can register a ClassFileTransformer, which is invoked before each class is loaded.

public class MyAgent {
    public static void premain(String agentArgs, Instrumentation inst) {
        inst.addTransformer(new MyClassFileTransformer());
    }
}

class MyClassFileTransformer implements ClassFileTransformer {
    @Override
    public byte[] transform(ClassLoader loader, String className,
                            Class<?> classBeingRedefined,
                            ProtectionDomain protectionDomain,
                            byte[] classfileBuffer) throws IllegalClassFormatException {
        // Modify classfileBuffer using ASM/Byte Buddy
        if (className.equals("com/example/Service")) {
            return modifyWithByteBuddy(classfileBuffer);
        }
        return null; // No modification
    }
}

Agent-main (agentmain) and Dynamic Loading:

Starting with Java 6, agents can be loaded dynamically into a running JVM using com.sun.tools.attach.VirtualMachine.

VirtualMachine vm = VirtualMachine.attach("1234"); // PID of the process
vm.loadAgent("/path/to/my-agent.jar", "optional args");
vm.detach();

For this, the agent must have a public static void agentmain(String agentArgs, Instrumentation inst) method. This mechanism is used by many profilers (e.g., YourKit, Async-Profiler) and monitoring systems.

Key limitation of java.lang.instrument: You can add fields and methods or modify method bodies, but you cannot delete or change the signatures of existing fields/methods after a class has been loaded. Changes apply only to new classes or via retransformClasses().

JVMTI: Native Control over the JVM

JVMTI (JVM Tool Interface) is a native (C/C++) interface that provides the highest level of control over a running JVM. It succeeds older interfaces like JPDA (Java Platform Debugger Architecture). Through JVMTI, you can not only transform but also redefine and retransform already-loaded classes, and obtain detailed information about memory, threads, garbage collection, etc.

RedefineClasses: Replaces the implementation of one or more already-loaded classes with new bytecode versions. Restrictions: you cannot change method signatures, inheritance hierarchy, or fields.
RetransformClasses: Forces the JVM to re-apply ClassFileTransformer logic even to already-loaded classes, enabling new transformation rules to be applied globally.

// Simplified C example
jvmtiError error = jvmti->RedefineClasses(jvmti, 1, &classDefinition);

Where is JVMTI used?

Interactive debuggers (e.g., IntelliJ IDEA Debugger).
Production profilers (YourKit, JProfiler) that collect performance data with minimal overhead.
HotSwap tools (though standard IDE HotSwap is limited).
Security and monitoring systems requiring deep introspective access.

JVMTI is significantly more complex and dangerous than java.lang.instrument. An error in native code can crash the entire JVM. However, it provides unprecedented control, essential for professional diagnostic tools. These mechanisms demonstrate that the JVM is not just a runtime environment but an open platform for metaprogramming—where program behavior can be altered externally based on its internal state.

6. How Lombok, Spring, and Mockito Work

The theory of bytecode manipulation becomes truly tangible when we examine its use in widely adopted frameworks and libraries. These tools don’t rely on “magic”—they leverage deep JVM mechanisms we’ve already discussed. Understanding their internals reveals the practical value of knowledge about Class Loading and bytecode manipulation.

Lombok: Code Generation Behind the Scenes

Project Lombok is known for adding methods (toString, equals, getter, setter) via annotations. Its implementation combines two approaches:

Annotation Processing (AP): At compile time, when javac processes source code, Lombok registers its own Processor. This processor inspects the AST (Abstract Syntax Tree) and inserts nodes for missing methods directly into the syntax tree before bytecode is generated. This occurs within the standard compilation process.
Javac Internals / Instrumentation: For certain features (e.g., @SneakyThrows) or IDE integration, Lombok directly interacts with javac’s internal APIs (package com.sun.tools.javac.*) to modify the AST. At runtime, in some configurations, an agent (-javaagent) may be used for introspection, but the core work happens at compile time.

Key point: Lombok doesn’t generate separate .class files—it modifies the compilation of the current file. The resulting bytecode is identical to what would be produced if the methods were written manually, so it passes verification effortlessly.

Spring AOP and CGLIB: Proxying Without Interfaces

The Spring Framework heavily uses Aspect-Oriented Programming (AOP) to inject cross-cutting concerns (transaction management, security, logging). When a bean doesn’t implement an interface but a proxy is needed, Spring uses CGLIB.

CGLIB (Code Generation Library): This library (built on ASM) dynamically creates a subclass of the target class at runtime.
Mechanism: CGLIB analyzes the original class’s bytecode, generates a new class that extends it, and overrides all public and protected methods. In the overridden methods, it inserts calls to a Callback (e.g., MethodInterceptor) that manages the original method invocation and aspect execution.

// Pseudocode of what CGLIB generates
public class UserService$$EnhancerByCGLIB extends UserService {
    private Callback callback;

    @Override
    public void save(User user) {
        callback.intercept(this, saveMethod, new Object[]{user}, null);
    }
}

This subclass is generated in memory, its bytecode is passed to ClassLoader#defineClass, and an instance of this class is used instead of the original. This approach allows Spring to apply AOP to any class—but requires that the class and its methods are not final.

Mockito: Creating Mocks Out of Thin Air

Mockito—one of the most popular testing libraries—also relies on bytecode manipulation. When you write mock(MyUserService.class), Mockito must create an object that:

Is an instance of MyUserService (or its subclass),
Doesn’t execute real logic,
Can record calls and return stubs.

To achieve this, Mockito uses Objenesis and Byte Buddy:

Instance creation: Objenesis uses low-level JVM capabilities (often via sun.misc.Unsafe.allocateInstance()) to instantiate a class without invoking its constructor.
Proxy generation: Byte Buddy generates a subclass of the mocked class. All method calls on the mock are intercepted, recorded, and handled according to configured behavior (e.g., when(...).thenReturn(...)). This entire process occurs at runtime during test execution and is fully based on ClassLoader and Instrumentation capabilities.

Observability Agents (OpenTelemetry, Micrometer)

Modern APM systems attach as agents (-javaagent) and register a ClassFileTransformer. When classes matching certain patterns are loaded (e.g., methods annotated with @RequestMapping, @Timed, or HTTP client entry points), the agent modifies their bytecode to insert calls to tracing or metrics SDKs. This enables telemetry collection without modifying the application’s source code.

Conclusion: Power and Responsibility

We’ve journeyed from class loading to runtime modification.

We’ve seen how verification protects the JVM, how .class stores code, and how ASM, Byte Buddy, and JVMTI grant us control over it.

These mechanisms form the foundation of the modern Java ecosystem. Without them, tools like Spring (with its proxying and dependency injection), Mockito (with its flexible mocks), Lombok (with its concise annotations), or powerful APM systems (which provide deep performance insights without code changes) wouldn’t exist. They transform Java from a static language into a platform rich with metaprogramming capabilities.

However, with great power comes great responsibility:

Performance: Every runtime intervention takes time. A poorly implemented ClassFileTransformer can slow application startup by orders of magnitude.
Complexity and Debugging: Errors in generated bytecode lead to VerifyError or IllegalAccessError, which are extremely hard to diagnose. Stack traces lose their connection to source code.
Memory Leaks: Custom ClassLoaders, if not properly released, retain all their loaded classes and static data in memory, causing metaspace leaks.
Compatibility: Tools written for one JVM version may break in another.
Security: The ability to modify any class opens the door to serious vulnerabilities if the agent or instrumentation isn’t trusted.

Nevertheless, understanding these mechanisms is essential for any developer aiming to go beyond boilerplate programming. It enables you to:

Deeply understand the frameworks you use,
Diagnose complex class-loading and performance issues,
Build your own tools for monitoring, testing, and extending functionality.

P.S. Have you encountered memory leaks due to custom ClassLoaders? Or perhaps written your own monitoring agent? Share your experience in the comments—it will be valuable for everyone!

How I Deployed a Java Spring Boot + Angular SSR Website Using Docker and Nginx: A Personal Journey

Aleksandr Tiurin — Sat, 31 May 2025 11:16:03 +0000

This is a real-world story — with challenges, solutions, and valuable lessons that may benefit other developers or serve as a reference for myself in the future.

Introduction

The project is a web application built with Spring Boot and Angular. Initially, I went with a simple monolithic architecture, but as the requirements and ambitions grew, I had to switch to a microservices-based structure. Here's how it all happened — including configurations, issues, and solutions.

Monolithic Architecture

Initial setup:

Backend: Spring Boot
Frontend: Angular I already had a rented VDS, so I registered a domain via a well-known provider and decided to host the site on that VDS. To keep things simple, I integrated the Angular build into the Spring Boot resources using frontend-maven-plugin, bundling everything into a single JAR file.

Why? I had done it before and it worked, so I chose the familiar path.

After registering the domain (which takes some time to propagate), I began configuring and testing the project. But during testing, major drawbacks surfaced:

No SSR in Angular → SEO was negatively impacted
Fragile build: Angular errors broke Maven build
Maintenance and scalability became difficult

Moving to Microservices

I decided to split the frontend and backend into separate services and introduce Angular Universal for SSR. Here's the updated architecture:

Backend: Spring Boot
Frontend: Angular Universal (SSR)
Infrastructure: Docker Compose, Nginx, HTTPS

Docker, Nginx and Initial Launch

Base docker-compose.yml setup:

services:
  frontend-service:
    image: node:18-alpine
    command: node server/main.js

  backend-service:
    image: amazoncorretto:17-alpine-jdk
    command: java -jar app.jar

  nginx:
    image: nginx:alpine
    # Proxy configuration

Initial Nginx config:

server {
    server_name my-site.ru;

    location / {
        proxy_pass http://frontend-service:9002;
    }

    location /api {
        proxy_pass http://backend-service:9001;
    }
}

The site started and worked via IP, but there were many issues:

Duplicated API prefixes (/api/api/endpoint) → Fixed proxy_pass and Angular API base URL
Redirects on POST requests due to Spring adding extra slashes → Fixed via correct controller annotations and Nginx tuning
405 Method Not Allowed → Fixed by explicitly using @PostMapping
Docker networking issues → Resolved by defining a shared network in docker-compose.yml

Security: HTTPS, SSL, CORS

To make the site accessible via domain name, I configured DNS records through my provider (they offer free DNS). I pointed @ and www to the VDS IP address.

The domain provider also offered free SSL certificates (Let's Encrypt). Here's how I set them up: downloaded from the provider panel:

domain.crt — certificate
domain.key — private key
ca_bundle.crt — certificate chain

Nginx HTTPS configuration:

listen 443 ssl;
ssl_certificate /etc/nginx/ssl/domain.crt;
ssl_certificate_key /etc/nginx/ssl/domain.key;
ssl_trusted_certificate /etc/nginx/ssl/ca_bundle.crt;

However, HTTPS failed to work initially. The Nginx logs showed SSL_CTX_use_PrivateKey_file errors. The issue? The certificate was in PKCS#7 format, but Nginx requires PEM. I converted it using OpenSSL:

openssl pkcs7 -print_certs -in domain.p7b -out domain.crt

Also, since certificates expire, don't forget to renew them. Eventually, I plan to automate this (e.g. with Certbot).

On the Spring Boot side, CORS errors were solved like this:

@Bean
public WebMvcConfigurer corsConfigurer() {
    return new WebMvcConfigurer() {
        @Override
        public void addCorsMappings(CorsRegistry registry) {
            registry.addMapping("/api/**")
                    .allowedOrigins("https://example.com");
        }
    };
}

Bot Attacks and Protection

Soon after launching the site, Nginx logs filled with automated bot requests probing for WordPress, PHPMyAdmin, etc. Example:
45.155.205.213 - - [01/Jan/2023:04:12:11 +0000] "GET /wp-login.php HTTP/1.1" 404 153
Nginx protection rules:

location ~* ^/(wp-admin|wp-login|phpmyadmin|.env|config.php) {
    return 403;
}

if ($request_method ~ ^(TRACE|TRACK|DEBUG)) {
    return 405;
}

Final Configuration

After several iterations, here’s what my current setup looks like:

docker-compose.yml

version: '3.8'

networks:
  app-network:

services:
  backend-service:
    build:
      context: ./backend
      dockerfile: Dockerfile
    container_name: backend-service
    ports:
      - "9001:9001"
    volumes:
      - ./backend/logs:/app/logs
    env_file:
      - ./.env
    restart: always
    networks:
      - app-network

  frontend-service:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    container_name: frontend-service
    ports:
      - "9002:9002"
    environment:
      - NODE_ENV=production
    restart: always
    networks:
      - app-network

  proxy-service:
    image: nginx:alpine
    container_name: proxy-service
    volumes:
      - ./nginx/conf:/etc/nginx/conf.d:ro
      - ./ssl-certs:/etc/nginx/ssl:ro
      - ./nginx/logs:/var/log/nginx
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - backend-service
      - frontend-service
    restart: always
    networks:
      - app-network

nginx.conf

worker_processes auto;

events {
    worker_connections 1024;
}

http {
    upstream frontend {
        server frontend-service:9002;
    }

    upstream backend {
        server backend-service:9001;
    }

    server {
        listen 80;
        server_name example.com www.example.com;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        server_name example.com www.example.com;

        ssl_certificate /etc/nginx/ssl/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;

        add_header Strict-Transport-Security "max-age=31536000" always;

        location / {
            proxy_pass http://frontend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        location /api/ {
            proxy_pass http://backend/api/;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }

        location ~* ^/(wp-admin|wp-login|phpmyadmin|.env|config.php) {
            return 403;
        }

        if ($request_method ~ ^(TRACE|TRACK|DEBUG)) {
            return 405;
        }
    }
}

backend Dockerfile

FROM amazoncorretto:17-alpine-jdk
WORKDIR /app
COPY my-spring-1.0.jar app.jar
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

frontend Dockerfile

FROM node:18-alpine AS runtime
WORKDIR /app
COPY browser /app/browser
COPY server /app/server
COPY node_modules /app/node_modules
EXPOSE 4000
CMD ["node", "/app/server/server.mjs"]

Conclusion

The website is now fully up and running. Splitting services made it more maintainable and scalable. Hopefully, this post will help others going down a similar path with Java and Angular.

DEV Community: Aleksandr Tiurin

Project Valhalla: Fundamental Changes in the JVM

Is Valhalla a Practical Lifesaver for Data-Intensive Code?

The Problem: Parsing Financial XML

Value Types in Action

What This Means at the CPU and Memory Level

Before (Classic Java):

After (With Valhalla):

Let’s Build a Practical Benchmark (Prototype on a Valhalla EA Build)

Why XML Parsing Benefits So Much From This Approach

My Experiment: A StAX Parser With Valhalla

What Will Need to Change in Real Projects?

Real-World Use Cases

1. High-Frequency Market Data Parsing (FIX/FAST, XML)

2. Payment Validation With Transformation Chains

3. Caching Frequently Used Keys

Conclusion

Where to Track Progress

No Magic: How Spring, Lombok, and Mockito Actually Work Under the JVM Hood

Introduction: It’s Not Reflection—It’s Bytecode

1. Class Loading: Delegation, Isolation, Customization

2. Linking Phase: Verification, Preparation, Resolution

Verification: The Guardian of JVM Integrity

Preparation: Memory Allocation for Static Members

Resolution: Resolving Symbolic References

3. Bytecode and Class File Format: The Structure of .class

ClassFile Structure

Bytecode: The Language of a Stack Machine

4. Bytecode Manipulation: ASM, Byte Buddy, Javassist

ASM: Low-Level Control

Byte Buddy: A Modern DSL over ASM

Javassist: Source-Like Code Manipulation

Choosing the Right Tool

5. Runtime Instrumentation: java.lang.instrument and JVMTI

java.lang.instrument: Dynamic Transformation

JVMTI: Native Control over the JVM

6. How Lombok, Spring, and Mockito Work

Lombok: Code Generation Behind the Scenes

Spring AOP and CGLIB: Proxying Without Interfaces

Mockito: Creating Mocks Out of Thin Air

Observability Agents (OpenTelemetry, Micrometer)

Conclusion: Power and Responsibility

How I Deployed a Java Spring Boot + Angular SSR Website Using Docker and Nginx: A Personal Journey

Introduction

Monolithic Architecture

Moving to Microservices

Docker, Nginx and Initial Launch

Security: HTTPS, SSL, CORS

Bot Attacks and Protection

Final Configuration

Conclusion

`java.lang.instrument`: Dynamic Transformation