Forem: Satyadev Neti

Immutable List in Java

Satyadev Neti — Mon, 04 May 2026 18:10:09 +0000

Engineering Craftsmanship: Building a Sovereign Immutable List in Java

In an era of "vibe coding" and AI-driven bloat, there is a distinct value in returning to the fundamentals of structural integrity. As I navigate a career pivot toward Site Reliability Engineering (SRE) and Senior Development, I’ve found that the most resilient systems are those built on the principles of data sovereignty and immutability.

Recently, I decided to step away from the standard java.util collections to build something more robust: a truly immutable, persistent linked list using Java 21/25 features.

Why "Sovereign"?

The term "Sovereign" reflects a commitment to local-first software. In a world obsessed with mandatory cloud sync, a sovereign application operates entirely offline, ensuring the user has total ownership of their data. To support this architecture, the underlying data structures must be:

Thread-Safe by Design: Immutability eliminates the need for complex locking mechanisms.
Memory Efficient: Utilizing structural sharing to minimize overhead.
Modern: Leveraging the latest JVM capabilities like Sealed Interfaces and Records.

The Architecture: Sealed Interfaces + Records

By using a sealed interface, we create what functional programmers call a Sum Type. This ensures that our list can only ever be one of two things: Nil (empty) or Cons (a head element and a tail).

The Implementation

package io.sovereign.collections;

import java.util.NoSuchElementException;

public sealed interface ImmutableList<T> permits ImmutableList.Nil, ImmutableList.Cons {

    record Nil<T>() implements ImmutableList<T> {}

    record Cons<T>(T head, ImmutableList<T> tail) implements ImmutableList<T> {}

    default ImmutableList<T> prepend(T value) {
        return new Cons<>(value, this);
    }
}

This structure allows for Structural Sharing. When you prepend an item to the list, you aren't copying the entire array. Instead, you are creating a new Cons node that points to the existing list. This operation is $O(1)$, making it incredibly performant even as the data grows.

Performance and the SRE Mindset

In this implementation, I specifically optimized the functional operations. While map and filter are functional concepts, I implemented them using iterative loops internally. This avoids the dreaded StackOverflowError on large datasets that purely recursive implementations often face on the JVM. It is the balance of functional purity and system-level pragmatism.

Looking Ahead: Project Valhalla

This project isn't just about today; it's about the future of Java. By using Records, this code is already positioned to take advantage of Project Valhalla. Once Value Types land in the JVM, these nodes will have the memory density of primitives, further closing the gap between high-level abstractions and low-level performance.

Conclusion

Building the Sovereign List was an exercise in intentionality. It's a reminder that as software engineers, we aren't just assemblers of libraries; we are craftsmen of systems.

Check out the full source code on GitHub:

devsatya / sovereign-list

A high-performance, persistent, and thread-safe Immutable List for Java, optimized for structural sharing and Project Valhalla.

Sovereign Collections: ImmutableList

A high-performance, persistent, and truly immutable singly-linked list engineered for the modern Java ecosystem (Java 21 to Java 25+).

ImmutableList is built on the principles of Data Sovereignty. It ensures that once data is recorded, it can never be altered by side-effects, race conditions, or external processes. This makes it the ideal foundation for local-first applications, SRE tooling, and privacy-centric software.

🛠 Why ImmutableList?

Traditional Java collections like ArrayList are mutable, leading to defensive copying and complex synchronization in multi-threaded environments. ImmutableList solves this through Persistence and Structural Sharing.

1. Structural Sharing

Instead of deep-copying data, ImmutableList shares existing nodes between different versions of a list. When you prepend an item, a new head is created that points to the original list.

Memory Efficiency: Additions are $O(1)$.
Zero Data Duplication: Your original data remains untouched and shared in memory.

2. Thread Safety

…

View on GitHub

About the Author

I am a Software Developer and SRE based in Hyderabad, currently refining my craft on Ubuntu and exploring the depths of the Java ecosystem.

👻 The Ghost of the Ancestor: A Memory Horror Story in Go, Java, and Rust

Satyadev Neti — Wed, 29 Apr 2026 07:02:58 +0000

In the world of high-performance programming, we are obsessed with Slices. We want to take a small piece of a large dataset without copying it. It’s fast. It’s efficient.

But it’s haunted.

Let’s look at how three of the world's most popular languages deal with the "Ghost of the Ancestor"—the phenomenon where a tiny "descendant" slice keeps a massive "ancestor" array alive in memory forever.

The Setup: Go’s "Hidden" Connection

In Go, a slice is just a small header pointing to a big array. Notice how scores2 is built from scores1.

package main
import "fmt"

func main() {
    // Original Go Logic
    scores := make([]int, 0, 5)
    scores1 := make([]int, 0, 5)
    scores2 := make([]int, 0, 5)

    scores = append(scores, 234, 242, 53, 42, 353)
    fmt.Println("Scores :", scores, "Len:", len(scores))

    scores1 = append(scores1, 234, 242, 53, 42, 353, 1111)
    fmt.Println("Scores1 :", scores1, "Len:", len(scores1))

    // Here Slices grow itself, but they still share an ancestor!
    scores2 = append(scores1, 234, 242, 53, 42, 353)
    fmt.Println("Scores2 :", scores2, "Len:", len(scores2))

    myscores := make([][]int, 0, 3)
    myscores = append(myscores, scores, scores1, scores2)
    fmt.Println("Slices of slices :", myscores, "Len:", len(myscores))
}

The Dialogue: When Languages Collide

Go: "Look at me! I’m lean. I’m fast. My slices are just headers—a pointer, a length, and a capacity. If I want to give you a piece of an array, I just point you to the memory. No copying, no overhead!"

Java: (Sips coffee) "That’s cute, Go. But you’re playing with fire. By sharing that 'underlying array,' you’re inviting side effects. In my world, we prefer objects. When you create an ArrayList from another, I usually copy the data. It’s safe. It’s clean. The Garbage Collector knows exactly when to kill an old list."

Go: "Safety is just another word for 'slow,' Java. My developers know what they’re doing... Wait, what’s this?"

Go points at Java’s standard library.

Go: "You have a subList() method, Java. If I take a subList of a 1GB ArrayList, does that 1GB stay in RAM even if the original list is 'deleted'?"

Java: (Sweating) "Well... technically... yes. The SubList is a nested class that holds a reference to the parent. So the GC can't collect the parent as long as the child lives. We call it 'Memory Pinning.'"

The Java "Ghost" Replicated:

package io.lagresearch.jgo;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public class NoGhost {
    public static void main(String[] args) {
        // 1. Create independent ArrayLists
        // Equivalent to Go's: scores := make([]int, 0, 5)
        ArrayList<Integer> scores = new ArrayList<>(Arrays.asList(234, 242, 53, 42, 353));
        ArrayList<Integer> scores1 = new ArrayList<>(Arrays.asList(234, 242, 53, 42, 353, 1111));

        // 2. Creating scores2 as an independent copy of scores1
        // In your Go code: scores2 = append(scores1, 234...)
        ArrayList<Integer> scores2 = new ArrayList<>(scores1);
        scores2.addAll(Arrays.asList(234, 242, 53, 42, 353));

        System.out.println("Scores 1: " + scores1);
        System.out.println("Scores 2: " + scores2);

        // 3. Creating the "Slice of Slices" (ArrayList of ArrayLists)
        ArrayList<ArrayList<Integer>> myScores = new ArrayList<>();
        myScores.add(scores);
        myScores.add(scores1);
        myScores.add(scores2);

        System.out.println("My Scores (Nested): " + myScores);

        // --- THE "GHOST OF THE ANCESTOR" TEST ---

        // In Java, if we use subList, it behaves like a Go slice (a "view")
        List<Integer> ancestor = new ArrayList<>();
        for (int i = 0; i < 1000; i++) ancestor.add(i);

        // This 'descendant' is a VIEW. It keeps 'ancestor' alive in memory.
        List<Integer> descendant = ancestor.subList(0, 5);

        // Proof of "pointing": Change the ancestor, the descendant changes!
        ancestor.set(0, 999);
        System.out.println("Descendant index 0: " + descendant.get(0)); // Output: 999

    }

}

Enter: Rust (The Exorcist)

Rust: "Did someone say memory leaks? You two are arguing over who lets the ghost in more often. In my house, we don't have ghosts unless you explicitly summon them."

Go & Java: "Show-off. How do you handle it?"

Rust: "Ownership. If you want a slice, you 'borrow' it. While you're borrowing it, the Ancestor is locked. And if you try to delete the Ancestor while the Descendant is looking at it, I simply refuse to compile your program."

The Rust "Explicit Ghost":

fn main() {
    let mut scores: Vec<i32> = Vec::with_capacity(5);
    let mut scores1: Vec<i32> = Vec::with_capacity(5);
    let mut scores2: Vec<i32> = Vec::with_capacity(5);

    scores.extend([234, 242, 53, 42, 353]);
    println!("Scores  : {:?} | Len: {}", scores, scores.len());

    scores1.extend([234, 242, 53, 42, 353, 1111]);
    println!("Scores1 : {:?} | Len: {}", scores1, scores1.len());

    // scores2 built from scores1 (clone to avoid borrowing issues)
    scores2.extend_from_slice(&scores1);
    scores2.extend([234, 242, 53, 42, 353]);
    println!("Scores2 : {:?} | Len: {}", scores2, scores2.len());

    let myscores = vec![scores, scores1, scores2];

    println!("\nWe now have {} vectors inside myscores", myscores.len());
}

Visualising the Haunting

The Verdict

Go is the "Wild West": You get maximum speed and direct pointer control, but append can link your descendants to your ancestors forever. You must manually "cut the cord" (using the 3-index slice a[0:2:2]) to stop the Ghost from haunting your RAM.
Java is the "Gated Community": It feels safe with its "copy-by-default" approach, but subList is a hidden trapdoor. It creates a reference chain that can sink your heap by pinning massive parent arrays in memory.
Rust is the "High-Security Vault": No ghosts allowed by default. The compiler forces you to acknowledge a reference's existence through strict ownership and borrowing rules. To share state, you must be explicit—otherwise, you clone() and stay safe.

The Lesson: Every time you take a slice without copying, you aren't just taking data. You're taking a responsibility. Don't let your ancestors haunt your production servers. 👻