DEV Community: Guna SantoshDeep Srivastava

JVM Architecture Explained: The Heart of Java (Class Loader, Runtime Data & Execution Engine)

Guna SantoshDeep Srivastava — Tue, 18 Aug 2026 08:29:39 +0000

The JVM is the one thing every Java developer uses constantly and understands the least. You know it "runs your bytecode," but if someone asked you to actually walk through what happens between java MyApp and your program executing, most people go quiet after "well, it loads the class." Here's the whole thing, one piece at a time — and if you want to go even deeper than this article after reading, the official Java Virtual Machine Specification is the actual source all of this is based on.

1. Class Loader Subsystem — getting your code into memory

This is the part responsible for taking your .class files and loading them into memory. It happens in three steps, always in this order.

Loading — reads the .class file and creates a corresponding Class object in memory. This is handled by one of three loaders, each responsible for a different source:

Bootstrap Class Loader — loads core Java classes (java.lang.*, etc.) from the JDK itself
Platform Class Loader (formerly called the Extension Class Loader) — loads classes from platform/extension libraries like java.sql.*
Application (System) Class Loader — loads your own classes, from your classpath

Linking — happens in three sub-steps:

Verification — checks the bytecode is valid and safe, and follows JVM rules. This is a real security boundary, not just a formality — it's what stops malformed or tampered bytecode from running.
Preparation — allocates memory for static variables and sets them to default values (0, false, null)
Resolution — converts symbolic references (like a class or method name) into actual, direct references

Initialization — runs static initializer blocks and assigns the real values to static variables. This only happens once per class, and only right before the class is actually used for the first time.

2. Runtime Data Areas — where everything actually lives in memory

These are created while your program runs, and they split into two categories: shared across all threads, or private to a single thread.

Shared by all threads:

Method Area — stores class structure, method data, the runtime constant pool, and bytecode itself. In Java 7 and earlier this lived in a space called PermGen; since Java 8, it's called Metaspace instead.
Heap — where every object and array created with new actually lives. This is what the Garbage Collector manages automatically. You can control its size with the -Xms (initial size) and -Xmx (max size) flags.

Private to each thread:

Java Stack — every thread gets its own. Each method call pushes a new "stack frame" containing local variables, an operand stack, and frame data (like the return address). Created when a thread starts, destroyed when it ends.
PC Register — tracks the address of the instruction the thread is currently executing. Every thread needs its own, since each one is at a different point in the program.
Native Method Stack — used specifically when the JVM needs to manage calls into native (C/C++) code.

3. Execution Engine — actually running the bytecode

This is what turns loaded bytecode into your program actually doing something.

Interpreter — reads and executes bytecode line by line. Simple, but slow, since it re-interprets the same instructions every time they run.
JIT Compiler (Just-In-Time) — watches for bytecode that runs frequently, and compiles that into native machine code instead, so it runs at near-native speed from then on.
Garbage Collector — automatically finds objects in the Heap and Method Area that are no longer reachable, and reclaims that memory, so you don't have to manually free it yourself. If you ever need to actually tune this in production, Oracle's official Garbage Collection Tuning Guide covers the different collectors (G1, Parallel, ZGC) and when to reach for each one.

The interpreter and JIT compiler work together, not separately: everything starts out interpreted, and the "hot" code — the parts actually running a lot — gets bumped up to compiled native code over time.

4. JNI (Java Native Interface) — the bridge to C/C++

JNI is what lets JVM code call out to native code, and vice versa. This matters for system-level work that pure Java can't do on its own — low-level I/O, hardware access, or reusing an existing native library instead of rewriting it in Java.

5. Native Method Libraries

These are the actual native (C/C++) libraries that JNI calls into — things like file handling, network communication, hardware access, or compression libraries that need to operate below the level Java itself normally works at.

The complete flow, start to finish

MyApp.java
   → javac (compiler)
   → MyApp.class (bytecode)
   → Class Loader Subsystem (Loading → Linking → Initialization)
   → Runtime Data Areas (memory allocated)
   → Execution Engine (Interpreter / JIT + Garbage Collector)
   → JNI (if native code is involved)
   → Native Libraries (if needed)
   → Output

Class loader hierarchy: parent delegation

The three class loaders aren't independent — they're arranged in a hierarchy, and they follow something called the parent delegation model:

Bootstrap Class Loader
      ↑ (parent)
Platform Class Loader
      ↑ (parent)
Application Class Loader

When a class needs loading, the Application loader doesn't just load it directly — it first asks its parent (Platform), which asks its parent (Bootstrap). Only if none of the parents can find the class does the request fall back down the chain. This is why you can't accidentally override a core class like java.lang.String just by defining your own class with the same name — the Bootstrap loader already owns that name, and it's asked first.

Quick answers, if this comes up in an interview

"What are the three main JVM subsystems?" → "Class Loader Subsystem, Runtime Data Areas, and the Execution Engine."
"What's the difference between the Method Area and the Heap?" → "The Method Area stores class-level data — structure, bytecode, the constant pool. The Heap stores actual object instances created with new. Both are shared across all threads."
"Why does each thread get its own stack, but not its own heap?" → "Objects need to be shared between threads, so the Heap is shared. But each thread executes independently, so it needs its own call stack to track its own method calls."
"What replaced PermGen, and why?" → "Metaspace, starting in Java 8. Unlike PermGen, Metaspace isn't part of the JVM's fixed heap — it uses native memory and can grow dynamically, which avoids the classic OutOfMemoryError: PermGen space problem."
"What is the parent delegation model?" → "Before a class loader loads a class itself, it asks its parent loader first. This prevents core Java classes from being silently overridden by user-defined classes with the same name."

The short version

The JVM isn't one thing — it's three subsystems working together: the Class Loader gets your code into memory (loading, linking, initialization), the Runtime Data Areas hold everything while it runs (shared Method Area and Heap, plus a private Stack, PC Register, and Native Stack per thread), and the Execution Engine actually runs it (interpreter and JIT compiler, with garbage collection running alongside). JNI and native libraries exist for the moments Java code needs to reach outside the JVM entirely. Understanding this flow is what separates "the JVM runs my code" from actually knowing what your program is doing at runtime.

JDK vs JRE vs JVM: The JRE Download Doesn't Exist Anymore

Guna SantoshDeep Srivastava — Tue, 18 Aug 2026 08:07:16 +0000

Ask a junior developer to explain JDK, JRE, and JVM, and you'll usually get "JDK is for developers, JRE is for running apps, JVM executes the code" — which is correct, but based on how Java worked before 2018. If you've tried to download a standalone JRE recently and couldn't find one, that's not a broken link. That's an actual, permanent change to how Java is packaged. Let's cover both the classic explanation and what's actually true today.

The three pieces, in plain terms

JDK (Java Development Kit) — everything you need to build Java applications: a compiler, debugging tools, and (traditionally) a runtime to actually run what you built.
JRE (Java Runtime Environment) — everything you need to run an already-built Java application, but not build one.
JVM (Java Virtual Machine) — the actual engine that executes your compiled code. It's the one piece that's platform-specific — there's a different JVM build for Windows, Linux, and Mac, which is exactly what makes "write once, run anywhere" possible.

The classic way to remember the relationship: JDK contains JRE, and JRE contains JVM.

JDK
 └── JRE
       └── JVM

How a Java program actually gets from code to output

MyProgram.java  →  javac (compiler)  →  MyProgram.class (bytecode)  →  JVM  →  Output

You write code in a .java file
javac, the Java compiler (part of the JDK), compiles it into bytecode — a .class file
The JVM loads that bytecode and executes it
You get your program's output

A real example:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, Java!");
    }
}

Compile it with javac HelloWorld.java, then run it with java HelloWorld. The compile step needs the JDK. The run step only needs a JVM.

A simple way to picture it

Think of it like cooking:

JDK = a kitchen, ingredients, a chef, and tools — you can cook and serve a meal
JRE = a kitchen and ingredients only — you can eat a meal someone already cooked, but you can't cook one yourself
JVM = just the stove — the one part that actually does the cooking

Side-by-side comparison

Feature	JDK	JRE	JVM
Full form	Java Development Kit	Java Runtime Environment	Java Virtual Machine
Purpose	Develop, compile, debug, run	Run Java applications	Execute bytecode
Can compile?	Yes	No	No
Can run?	Yes	Yes	Yes
Used by	Developers	End users (historically)	JRE / the system itself
Platform independent?	Yes	Yes	No — a specific JVM build exists per OS

The part most tutorials get outdated on

Here's the correction that actually matters if you're working with any current Java version: Oracle stopped offering a separate, standalone JRE download starting with Java 11, released in 2018. This wasn't a small tweak — it was a deliberate architecture change.

A few real reasons this happened:

Java 9 introduced modules (Project Jigsaw), which broke the JDK into smaller, composable pieces instead of one fixed bundle
That made the old "one-size-fits-all JRE" concept mostly unnecessary
Instead, Oracle now expects you to either install the full JDK (which includes everything needed to run code too), or build a custom, smaller runtime using a tool called jlink

A real jlink example, building a minimal runtime with only what a specific app needs:

jlink --add-modules java.base --strip-debug --compress 2 --no-man-pages --output minimal-runtime

So if you're on Java 11 or later — meaning any current LTS version (11, 17, 21, or 25) — "install the JRE" isn't really an option anymore in the traditional sense. You install the JDK, whether you're developing or just running an application. The classic JDK/JRE split is still useful for understanding the architecture, but it no longer maps onto two separate downloads.

Where each one is actually used, in practice

JDK — used by developers in an IDE like IntelliJ or Eclipse, where compiling, debugging, and running all happen locally
JRE (conceptually) — the piece that still exists inside the JDK, doing the actual "running" work when you execute a program
JVM — used internally, both by developers running code locally and by production servers executing deployed applications; different builds exist for different operating systems

Quick answers, if this comes up in an interview

"What's the difference between JDK, JRE, and JVM?" → "JDK is the full development kit — compiler, tools, and a runtime. JRE is just the runtime, for running already-built apps. JVM is the actual engine that executes bytecode. JDK contains JRE, which contains the JVM."
"Can you run a Java program with just the JRE?" → "Yes — the JRE has everything needed to run compiled bytecode, but it doesn't include javac, so you can't compile new code with it."
"Why can't I find a JRE download anymore?" → "Because Oracle stopped offering a separate JRE as of Java 11. You install the JDK either way now, or build a custom minimal runtime with jlink."
"Is the JVM the same on every operating system?" → "No — the JVM itself is platform-specific. What's identical across platforms is the bytecode it runs, which is what makes Java portable."

The short version

JDK is for building software, JRE is for running it, and the JVM is the actual engine that executes your compiled bytecode — that's still the right mental model. What's changed is the packaging: since Java 11, there's no separate JRE download anymore. The JDK is the only official distribution, and if you need something smaller, jlink builds you a custom runtime instead. Understand the three roles, but don't go looking for a standalone JRE installer on a modern Java version — it isn't there.

Java Wasn't Built by One Person, and Sun Doesn't Own It Anymore

Guna SantoshDeep Srivastava — Mon, 10 Aug 2026 10:09:14 +0000

Ask someone who invented Java, and almost everyone says "James Gosling." That's true, but incomplete — he didn't build it alone. And if you ask "who owns Java today," a surprising number of developers still say Sun Microsystems, a company that hasn't existed since 2010.

Let's fix both of those gaps, then go through the actual list of features that make Java, Java — the ones that show up in almost every interview, explained properly instead of just named.

The people behind Java (not just Gosling)

In 1991, three people started the project at Sun Microsystems, not one:

James Gosling — the lead architect, often called "the father of Java"
Patrick Naughton — the engineer whose frustration with Sun's tools actually kicked off the project in the first place
Mike Sheridan — handled the business side, figuring out what market this project should actually target

Together they were known as the Green Team. And ownership has changed since then too: Oracle Corporation acquired Sun Microsystems in 2010 for $7.4 billion, and has owned and maintained Java ever since. If your mental model still says "Sun Microsystems owns Java," that's about 15 years out of date.

The 16 features that actually define Java

Every one of these gets mentioned in Java courses, but usually just as a name on a list. Here's what each one actually means, in plain terms.

#	Feature	What it actually means
1	Simple	No manual pointers, cleaner syntax than C++
2	Object-Oriented	Everything is built from classes and objects
3	Platform Independent	Same code runs on any OS via the JVM
4	Secure	No direct memory access, sandboxed execution
5	Robust	Strong memory management, structured exception handling
6	Portable	The same program moves between systems without changes
7	High Performance	The JIT compiler translates hot code into native instructions
8	Multithreaded	Built-in support for running multiple tasks at once
9	Distributed	Built-in support for networked applications (RMI, web services)
10	Dynamic	Classes can be loaded at runtime, not just compile time
11	Architecture Neutral	Not tied to any specific CPU or hardware design
12	Interpreted	Bytecode is executed by the JVM, not run directly on hardware
13	Automatic Memory Management	Garbage collection reclaims memory you're no longer using
14	Rich API	A huge standard library ships with the language itself
15	Compiled and Interpreted	Code compiles to bytecode first, then the JVM interprets/JIT-compiles it
16	Strong Community Support	Decades of libraries, frameworks, and answered Stack Overflow questions

A few of these are worth slowing down on, because they get misunderstood constantly.

Secure — what this actually protects against

"Secure" doesn't mean "immune to bugs." It means Java removes an entire category of bugs by design. In C, you can point directly at a memory address and read or write whatever's there — that's how buffer overflows and a huge share of classic security vulnerabilities happen. Java doesn't let your code touch memory addresses directly at all. Combined with the JVM's bytecode verifier (which checks code for illegal operations before running it), this is why Java became a popular choice for running code you don't fully trust, like early web applets.

Dynamic — the one people usually get wrong

This doesn't mean "dynamically typed" — Java is actually statically typed (you declare variable types up front). "Dynamic" here refers to class loading: Java can load new classes into a running program at runtime, instead of requiring every class to be known and linked at compile time. This is the same mechanism that lets a Java application load a plugin, or a server reload part of itself without a full restart.

Distributed — why this used to be a bigger deal than it sounds

Java shipped with RMI (Remote Method Invocation) built in — the ability to call a method on an object running on a completely different machine, almost as if it were local. In the mid-90s, this was a genuinely big deal; most languages didn't have anything like it built into the standard library. It's part of why Java became the default choice for a lot of early enterprise, networked software.

Write once, run anywhere — the quick version

This is covered in full depth in an earlier piece I wrote on why Java was created, but the short version: your .java file compiles to bytecode (.class), and the JVM — a different build for each OS — is what actually runs that bytecode. Same file, any machine, as long as a JVM exists for it.

MyProgram.java → compile (javac) → MyProgram.class (bytecode) → JVM → runs on Windows, Linux, or Mac

Quick answers, if this comes up in an interview

"Who created Java, and who owns it now?" → "James Gosling led the team, alongside Patrick Naughton and Mike Sheridan, at Sun Microsystems in 1991. Oracle acquired Sun in 2010 and has owned Java since."
"What does 'Java is secure' actually mean?" → "It removes direct memory access and pointer arithmetic, and the JVM verifies bytecode before running it — this eliminates whole categories of bugs common in languages like C."
"Isn't Java dynamically typed since it's called 'Dynamic'?" → "No — Java is statically typed. 'Dynamic' refers to loading classes at runtime, not variable typing."
"What's the difference between 'Compiled' and 'Interpreted' for Java, since it's supposedly both?" → "Java source compiles to bytecode first (compiled), then the JVM runs that bytecode by interpreting it and JIT-compiling the frequently used parts (interpreted + just-in-time compiled)."

The short version

Java wasn't a solo project — Gosling, Naughton, and Sheridan built it together, and Oracle has owned it since 2010, not Sun. The 16 features you'll see listed everywhere aren't just buzzwords: each one solves a specific, real problem from the pre-Java era, from memory-corruption bugs (secure) to "my code only runs on one machine" (platform independent, portable, architecture neutral). Knowing the reason behind each one is what separates reciting a list from actually understanding the language.

Java Evolution: LTS vs Non-LTS, and What's Actually Current Right Now

Guna SantoshDeep Srivastava — Mon, 10 Aug 2026 07:58:01 +0000

Ask five Java developers "should we upgrade to the new version?" and you'll usually get five different answers, because most people are quietly confused about the difference between an LTS release and a regular one. So here's Java's version history laid out clearly, plus the actual reasoning behind why some versions matter a lot more than others.

One quick note before we start: version timelines move fast, and even a well-made reference chart can go stale within months. I checked the current status of every version below, so this reflects where things actually stand today.

How Java got here: a quick timeline

1991 — James Gosling starts the project at Sun Microsystems (originally named Oak)
1996 — Java 1.0, the first official release
1997 — Java 1.2 (J2SE) adds the Collections Framework and Swing
2004 — Java 5 adds generics, annotations, and enums
2014 — Java 8 adds lambda expressions and the Streams API — arguably the biggest shift in how Java code is written
2018 — Java 11 becomes an LTS release
2021 — Java 17 (LTS) adds sealed classes and records
2023 — Java 21 (LTS) adds virtual threads
2025 — Java 25 (LTS) is the current long-term support version
2026 — Java 26 has already been released (more on this below)

LTS vs. Non-LTS: the difference that actually matters

Since Java 9, Oracle ships a new version every six months. But not all versions are treated the same:

LTS (Long-Term Support) — a version that gets security updates and bug fixes for years, usually 8 or more. These are the versions companies actually run in production.
Non-LTS (feature release) — a version that only gets 6 months of support before the next one replaces it. Great for trying out new features early, risky to run in production long-term since support runs out fast.

Think of it like phone operating systems: LTS releases are like a "stable" update you can trust for years, while non-LTS releases are more like a beta you use to see what's coming next.

Current LTS versions

Version	Released	Support commitment
Java 8	2014	Extended support into the early 2030s
Java 11	2018	Extended support winding down
Java 17	2021	Supported into 2029+
Java 21	2023	Supported into 2031+
Java 25	2025	Supported into the early 2030s (current LTS)

Exact support end dates shift as Oracle updates its policies, and they also differ depending on whether you're using Oracle's JDK or a free OpenJDK build from another vendor. For the real, current numbers, check Oracle's official Java SE Support Roadmap rather than trusting any single blog post or chart — this page gets updated as things change, most reference articles don't.

What's actually new in the versions people use today

Java 8 (2014) — the release most existing codebases were built on:

Lambda expressions and the Streams API
Optional, to reduce null-pointer bugs
A new Date & Time API

Java 11 (2018, LTS):

A proper HTTP client built in (java.net.http)
Local-variable type inference with var
Removed the old Java EE modules

Java 17 (2021, LTS):

Sealed classes, which let you control exactly which classes can extend a given class
Records, a compact way to write simple data-holder classes
Pattern matching improvements

Java 21 (2023, LTS):

Virtual threads (Project Loom) — lightweight threads that make handling thousands of concurrent tasks far cheaper
Record patterns and pattern matching for switch, both finalized
Sequenced Collections, giving collections a defined "first" and "last" element

Java 25 (2025, LTS, the current one):

Compact Object Headers, which shrink the memory every object uses
Flexible Constructor Bodies, finalized
Scoped Values, finalized

Correcting the record: Java 26 already shipped

If you've seen a chart listing "Java 26 (Upcoming)," that's now out of date — Java 26 was released on March 17, 2026. It's a non-LTS release, meaning 6 months of support before Java 27 takes over.

Java 26 finalized structured concurrency and flexible constructor bodies, and improved the Foreign Function & Memory API. Java 27 is scheduled for September 2026 — essentially right now, if you're reading this close to publish date. You can track exact release notes on OpenJDK's official JDK 26 project page.

LTS vs. Non-LTS, side by side

	LTS	Non-LTS
Support length	8+ years	6 months
Used for	Production systems	Trying new features early
Update frequency	Occasional patches	Replaced every 6 months
Examples	8, 11, 17, 21, 25	9, 10, 12, 13, 22, 23, 24, 26

How to check your Java version

java -version
javac -version

A real example of what that output looks like:

java version "25.0.1" 2025-10-21 LTS
Java(TM) SE Runtime Environment (build 25.0.1+9-LTS-27)
Java HotSpot(TM) 64-Bit Server VM (build 25.0.1+9-LTS-27, mixed mode, sharing)

That LTS tag in the version string is your quickest way to confirm whether you're on a long-term support version or a short-lived feature release.

Going deeper: why this is actually a licensing decision, not just a technical one

This is the part that trips up teams who've only ever worked with the free, open-source side of Java.

Oracle's official JDK builds come with a support lifecycle split into phases — Premier Support (full updates and patches) and Extended Support (patches available, usually at extra cost, for organizations not ready to upgrade). Once a version exits both phases, it moves to Sustaining Support, meaning no new security patches at all from Oracle — a real risk for anything handling sensitive data or subject to compliance requirements.

This is exactly why large companies plan Java upgrades years in advance instead of just "whenever." Falling behind on LTS versions isn't just a missed-features problem — once a version's support window closes, you're running unpatched software, which auditors and security teams take seriously.

If licensing cost is a concern, this is also why many companies run free OpenJDK builds (from vendors like Eclipse Adoptium, Amazon Corretto, or Azul) instead of Oracle's own JDK — same underlying code, different support and cost model. Worth knowing this distinction exists before assuming "Java" always means "Oracle's Java."

Quick answers, if this comes up in an interview

"What's the difference between LTS and non-LTS Java releases?" → "LTS versions get years of security updates and are meant for production. Non-LTS versions only get 6 months of support before the next release replaces them."
"Which Java version should a new project use?" → "The current LTS version, unless there's a specific new feature only available in a newer non-LTS release that's worth the shorter support window."
"How do you check what Java version you're running?" → "java -version from the terminal — the output also shows whether it's tagged LTS."
"Is Oracle's JDK the only option?" → "No — OpenJDK builds like Eclipse Adoptium or Amazon Corretto use the same underlying code and are free, with different support terms than Oracle's commercial JDK."

The short version

Java ships a new version every 6 months, but only some of those — the LTS releases — are meant to be run in production for years. Everything else is a short-lived preview of what's coming next. As of right now, Java 25 is the current LTS version, Java 26 has already been released as a short-term feature release, and Java 27 is due in September 2026. If you only remember one thing: check for the word "LTS" in your version string before deciding how long you can rely on it.

Java Was Built for TV Boxes, Not the Web — And It Almost Failed

Guna SantoshDeep Srivastava — Mon, 10 Aug 2026 07:36:17 +0000

Most Java developers can tell you Java is "write once, run anywhere." Almost none of them know it was originally built for interactive cable TV boxes, got rejected by the company it was pitched to, and only became the language we know today because the web happened to take off at exactly the right moment.

Here's the real story, plus why it still matters for how Java works today.

Before Java: why software development was a mess

In the early 1990s, writing software was genuinely painful, for a few concrete reasons:

Every platform needed its own language or its own version of your code — Windows wanted C/C++, UNIX wanted C, Mac wanted Objective-C
Code written for one machine simply wouldn't run on another
Development was slow and expensive because of all that duplicated work
Programs weren't very secure — memory bugs and viruses were common
Managing memory manually (allocating and freeing it yourself) was a constant source of bugs

If you've ever used malloc/free in C or dealt with a segfault, you already understand exactly the kind of pain this refers to.

How Java actually started

In 1991, James Gosling and a small team at Sun Microsystems started an internal project. The goal wasn't "build a programming language for the world" — it was much smaller: build software for consumer devices like set-top boxes, cable TV boxes, and home appliances.

The language they built for this was first called Oak, named after a tree outside Gosling's office. The project pitched itself to Time Warner for a set-top box deal — and lost. For a while, it genuinely looked like the whole thing might just die there.

Then the team noticed something: the World Wide Web was exploding in popularity, and it had the exact same core problem they'd already solved — needing to run the same code on wildly different machines. They pivoted the language toward the web instead of TV boxes.

Around 1995, "Oak" had to be renamed, since the name was already trademarked by another company (Oak Technology). The team picked Java — reportedly inspired by the coffee they were drinking during long brainstorming sessions. Sun Microsystems publicly announced Java in May 1995 at the SunWorld conference. The first actual public release, JDK 1.0, shipped a bit later, in January 1996.

What Sun Microsystems actually wanted

Gosling's team designed Java around a specific list of goals. In plain terms, they wanted a language that was:

Simple — easy to learn, without confusing features like manual pointers
Object-oriented — code organized around reusable objects, not just functions
Platform independent — the famous "write once, run anywhere"
Secure — no direct memory access, so a buggy program is far less likely to corrupt your system
Robust — strong error handling and automatic memory cleanup
Multithreaded — able to do multiple things at once
High performance — fast enough for real, demanding software
Architecture neutral — not tied to one specific type of computer chip

How "write once, run anywhere" actually works

This is the part most tutorials skip, and it's worth understanding properly because it explains why Java was designed the way it is.

Before Java, if you wrote a C++ program, you had to compile it separately for every operating system:

C/C++ program → compile for Windows → works only on Windows
              → recompile for Linux  → works only on Linux
              → recompile for Mac    → works only on Mac

Java changed the target of compilation. Instead of compiling straight to a specific operating system, Java compiles to something in between, called bytecode:

MyProgram.java  →  compile  →  MyProgram.class (bytecode)  →  runs on the JVM  →  works on Windows, Linux, or Mac

That .class file isn't native machine code, and it isn't source code either — it's bytecode, a kind of universal middle format. The JVM (Java Virtual Machine) is what actually understands bytecode and translates it into real instructions for whatever machine it's running on. Every operating system gets its own JVM, but the same .class file runs unmodified on all of them.

A tiny real example:

public class HelloJava {
    public static void main(String[] args) {
        System.out.println("Hello, Java!");
    }
}

Compile this once with javac HelloJava.java, and the resulting HelloJava.class file runs the same way on a Windows laptop, a Linux server, or a Mac — no recompiling needed.

The part that goes a bit deeper: how the JVM makes this both secure and fast

This is worth understanding if you want more than the textbook answer.

Security comes from the fact that Java code never touches memory directly. There's no pointer arithmetic like in C. Before the JVM even runs your bytecode, it runs it through a bytecode verifier that checks the code can't do illegal things like accessing memory it shouldn't. This is a big part of why Java become popular for running untrusted code (like early web applets) safely.

Performance comes from a clever hybrid approach. Early on, Java bytecode was simply interpreted line by line, which is portable but slow. Modern JVMs use a JIT (Just-In-Time) compiler instead — it watches your program while it runs, and translates the "hot" parts (code that runs a lot) into real native machine code on the fly. So you get the portability of bytecode and performance that gets closer to natively compiled languages, which is why a long-running Java server process actually speeds up the longer it runs.

Garbage collection is what handles Java's memory management automatically. Instead of you manually freeing memory (and risking a bug that frees it too early, or forgetting entirely), the JVM tracks which objects are no longer in use and reclaims that memory on its own.

Main reasons Java was created, side by side

Reason	What it actually means
Platform independence	Code runs on any OS through the JVM
Simplicity	No manual pointers, easier to learn than C++
Security	No direct memory access, built-in protections
Robustness	Automatic memory management, strong error handling
Object-oriented	Code built from reusable objects, not loose functions
Multithreading	Programs can do multiple things at once
Portability	The same program moves easily between systems
High performance	The JIT compiler makes bytecode run fast

Quick answers, if this comes up in an interview

"Why was Java created?" → "To solve the platform-dependence problem of the early 90s — code written for one machine couldn't run on another. Java compiles to bytecode that runs on any system with a JVM."
"Why was it called Oak first, then Java?" → "Oak was the original name, from a tree outside James Gosling's office. It got renamed to Java in 1995 because Oak was already trademarked by another company."
"What actually makes Java platform independent?" → "Java compiles to bytecode, not native machine code. Any system with a JVM can run that same bytecode, regardless of the underlying OS or hardware."
"How does the JVM make Java both secure and reasonably fast?" → "Security comes from bytecode verification and no direct memory access. Speed comes from the JIT compiler, which converts frequently used bytecode into native machine code while the program runs."

The short version

Java wasn't originally built for the web or for enterprise software — it was built for TV set-top boxes, nearly died after a failed pitch, and only became what it is today because it happened to solve the web's exact same "run anywhere" problem at the right moment. The core idea — compile once to bytecode, run it on a JVM anywhere — is still exactly why Java is portable, memory-safe, and fast today, decades later.

Java Collection Framework: The Interview Answer That Actually Impresses Interviewers

Guna SantoshDeep Srivastava — Fri, 07 Aug 2026 07:52:28 +0000

Every Java interview I've sat in on — on either side of the table — has some version of "explain the Collection Framework" in it. And almost every candidate can name ArrayList and HashMap, but the moment you ask "so why would you pick a LinkedList over an ArrayList here," things get shaky. So here's the whole framework laid out clearly, with the actual reasoning behind each piece, not just a list of class names to memorize.

What it actually is

The Java Collection Framework is a set of interfaces and classes for storing and working with groups of objects — think of it as Java's built-in toolkit for lists, sets, queues, and key-value maps, so you're not writing your own array-resizing logic from scratch.

Why it's worth using instead of rolling your own:

Dynamic size — no more manually resizing arrays
Built-in ways to store, search, sort, and update data
Better performance than anything most of us would hand-write ourselves
One shared set of interfaces, so code written against List works the same regardless of which actual implementation is plugged in

Oracle's own Collections Framework overview is worth bookmarking if you want the full official reference.

The shape of the framework

Everything branches from one interface: Collection. Three interfaces extend it — List, Set, and Queue — and then there's Map, which sits outside Collection entirely, as its own separate interface. That last part trips people up constantly in interviews: Map is part of the Collection Framework as a whole, but it does not extend the Collection interface itself.

List — ordered, and duplicates are fine

List keeps things in the order you put them in, and lets you access any item by its index.

Ordered
Allows duplicate values
Index-based access

List<String> names = new ArrayList<>();
names.add("Guna");
names.add("Ravi");
names.add("Guna"); // duplicates are fine
System.out.println(names); // [Guna, Ravi, Guna]

The main implementations, and when each one actually makes sense: ArrayList is backed by a resizable array, so it's fast to read by index but slower to insert or remove from the middle — it's the default choice unless you have a specific reason not to. LinkedList is backed by a chain of nodes instead, which flips that trade-off: faster inserts and removes at the ends, slower random access by index. Vector is basically ArrayList's older, synchronized sibling — you'll see it in legacy code far more than new code. And Stack is a legacy class that extends Vector, giving you last-in-first-out (LIFO) behavior.

Set — no duplicates allowed

Set is for when you need a group of things with no repeats.

No duplicate elements
Mostly unordered (with one notable exception below)

Set<String> ids = new HashSet<>();
ids.add("A");
ids.add("B");
ids.add("A"); // ignored, already exists
System.out.println(ids); // [A, B]

HashSet is the fastest general-purpose Set, but it makes no promises about order — don't rely on the sequence you get back. TreeSet is the exception mentioned above: it keeps its elements sorted automatically, at the cost of being a bit slower than HashSet.

Queue — first in, first out

Queue models a line, literally — first one in is the first one out (FIFO). Commonly used for task scheduling and buffering work.

Queue<Integer> tasks = new LinkedList<>();
tasks.add(10);
tasks.add(20);
tasks.add(30);
System.out.println(tasks.poll()); // 10, the first one in

PriorityQueue — items come out in priority order instead of strictly insertion order.
LinkedList — yes, the same class from the List section. It implements both List and Queue, so it can behave as either depending on how you use it.

Map — key to value, and it's not part of Collection

Map stores key-value pairs. This is the one worth repeating: Map does not extend Collection. It's part of the same framework conceptually, but it's a separate interface with its own hierarchy.

Stores key → value pairs
Keys are unique
Values can repeat

Map<Integer, String> users = new HashMap<>();
users.put(101, "Guna");
users.put(102, "Ravi");
users.put(103, "John");
System.out.println(users.get(101)); // Guna

HashMap — fast, makes no guarantee about key order.
LinkedHashMap — same as HashMap, but remembers insertion order.
TreeMap — keeps keys sorted automatically, same trade-off as TreeSet.

All four, side by side

Interface	Ordered	Duplicates	Example	Common classes
List	Yes	Allowed	`[A, B, A]`	ArrayList, LinkedList, Vector
Set	Mostly no (TreeSet: yes)	Not allowed	`{A, B, C}`	HashSet, TreeSet
Queue	Yes (FIFO)	Allowed	`10 → 20 → 30`	PriorityQueue, LinkedList
Map	Depends on implementation	Keys: no · Values: yes	`{101 → Guna}`	HashMap, LinkedHashMap, TreeMap

A memory trick that actually sticks

If you only remember one thing walking out of this article, make it this:

List → ordered, duplicates okay
Set → no duplicates
Queue → FIFO
Map → key → value, and it's the one that lives outside Collection

Quick answers, if you're prepping for an interview right now

If someone asks you these in an interview, here's the short version you can actually say out loud, in your own words:

"What is the Collection Framework?" → "It's a set of interfaces and classes for storing and managing groups of objects — List, Set, Queue, and Map — so I don't have to write my own resizing or searching logic."
"Is Map part of Collection?" → "No — Map is a separate interface. List, Set, and Queue all extend Collection, but Map doesn't."
"ArrayList or LinkedList — which do you use?" → "ArrayList by default, because most access patterns are reads by index. I'd reach for LinkedList only if I'm doing a lot of inserts or removes at the start or end."
"HashSet or TreeSet?" → "HashSet unless I specifically need the elements sorted — TreeSet does that automatically but costs a bit more performance."
"How does HashMap handle duplicate keys?" → "It doesn't allow them — putting a value at an existing key overwrites the old value instead of adding a second entry."

Practice saying these out loud once or twice. The goal isn't to recite them word-for-word — it's to internalize the reasoning well enough that you can rebuild the answer in your own words under pressure, which is exactly what a good interviewer is actually listening for.

The one-line interview answer

If you get asked to define it in one breath: "The Java Collection Framework is a unified architecture of interfaces and classes that provides efficient ways to store, manipulate, and retrieve groups of objects."

That's the textbook line — but if the interviewer follows up (and a good one will), being able to explain why Map sits outside Collection, or when you'd reach for a LinkedList over an ArrayList, is what actually separates a memorized answer from real understanding.

What's the one Collections question that's tripped you up in an interview, or tripped up someone you were interviewing? For me it's almost always the ArrayList-vs-LinkedList performance question — everyone knows the theory, fewer people can explain why in their own words.

HTTP Got a New Method After 16 Years — Meet QUERY (RFC 10008)

Guna SantoshDeep Srivastava — Thu, 16 Jul 2026 06:49:39 +0000

Quick trivia: before this year, the last time HTTP got a brand-new method was PATCH, back in 2010. That's a 16-year gap. In June 2026, that gap finally closed — the IETF published RFC 10008, officially adding a new method to HTTP: QUERY.

If you've ever needed to send a complex search or filter to an API and had to awkwardly choose between a messy GET URL or a POST that doesn't quite feel right, this method exists because of exactly that problem.

The problem QUERY is solving

For as long as HTTP has existed, reading data with parameters has meant picking between two imperfect options:

GET is safe, repeatable, and cacheable — but everything has to go in the URL. There's no guaranteed size limit (the spec only recommends a floor of 8000 characters), and complex data like nested filters or JSON just doesn't fit cleanly into a URL string. URLs also get logged far more often than request bodies, which is a real problem if your "search" contains anything sensitive.
POST can carry a full body, so complex data is easy to send — but nothing about POST tells a cache, proxy, or browser "this is just a read, nothing is changing." POST is treated as unsafe and non-repeatable by default, even when all you're doing is running a search.

QUERY is built to close that exact gap.

What QUERY actually is

Per the RFC itself, QUERY behaves like POST in form — it carries a full request body — but comes with the same reliability guarantees as GET:

Method	Has a body	Safe	Idempotent	Cacheable
GET	No	Yes	Yes	Yes
POST	Yes	No	No	Only in specific cases
QUERY	Yes	Yes	Yes	Yes

Safe means the client isn't asking to change anything on the server.
Idempotent means sending the same request twice has the same effect as sending it once — safe to retry.
Cacheable means a response can be reused for an identical request instead of hitting the server again.

Here's why those three properties aren't just theory — a concrete example of what actually breaks without them:

Say your app's network drops mid-request, and your HTTP client automatically retries. If that request was a POST, the client genuinely doesn't know whether the first attempt actually reached the server before the connection dropped. Retry, and you might run the same search twice — harmless for a search, but the exact same mechanism is why "retry on POST" is dangerous for something like a payment. The protocol gives the client no safe way to know it's okay to just try again.

If that same request had been a QUERY, the retry is a non-issue by definition — QUERY is idempotent, so running it twice has to produce the same result as running it once. Your HTTP client, your load balancer, and any proxy in between can all retry it automatically without asking anyone.

The caching angle plays out the same way: a CDN sitting in front of your API can cache a QUERY response and serve it instantly to the next identical request, the same way it already does for GET. It can never safely do that for a POST, because nothing in POST's contract says the response represents a stable, reusable answer.

On the wire, a QUERY request looks like this:

QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "category": "shoes",
  "price": { "lt": 100 },
  "sort": "newest"
}

Same shape as a POST, but the server (and any cache or proxy in between) knows this is a read-only request, not a write.

Where this actually helps

Complex search and filter endpoints — anything where the query itself is too big or too structured to fit nicely in a URL.
GraphQL queries — GraphQL reads are already safe and idempotent by design, but sending them as GET often blows past URL length limits. QUERY is a natural fit.
Anything currently using POST just to work around GET's limits — a pattern that's extremely common, and one that always meant giving up caching and the "safe" guarantee just to send a bigger request.

What's not ready yet

This is a brand-new standard, and it's important to be honest about where adoption actually stands as of mid-2026:

Browser support is still being evaluated — don't build a public-facing web app around it just yet.
QUERY is not a CORS-safelisted method, so browser JavaScript calling it across origins needs a preflight request, same as PUT or DELETE.
Popular frameworks are still catching up — Node.js has supported parsing QUERY since early 2024 (ahead of the RFC itself), and OpenAPI 3.2 already documents it, but Spring hasn't shipped built-in support as of this writing.
Existing infrastructure is a real concern: WAFs, API gateways, CDNs, and CSRF middleware are often configured around a fixed list of methods — GET, POST, PUT, DELETE, PATCH. Rule sets written before June 2026 may not know QUERY exists, and might reject it, or worse, handle it inconsistently.
Caching QUERY correctly means the cache key has to include the request body, not just the URL. A cache that gets this wrong opens the door to serving the wrong response to the wrong request.

How a client actually discovers QUERY is supported

You can't just assume every endpoint accepts QUERY — the server has to say so first. It does this with a response header called Accept-Query, usually seen after an OPTIONS request:

OPTIONS /products HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content
Allow: GET, POST, QUERY
Accept-Query: application/json

That Accept-Query: application/json line is the server telling any client: "yes, you can QUERY this endpoint, and send the body as JSON." Without it, a client has no reliable way to know whether QUERY will even be understood here — which is exactly why the gradual rollout (advertise it, then let clients adopt it) depends on this header existing in the first place.

How to actually roll this out

The sane path, based on what the RFC's authors themselves suggest, is gradual:

Keep your existing POST-based search endpoint working exactly as it is.
Add QUERY as a second way to reach the same endpoint.
Advertise support using the Accept-Query header, so clients can detect it.
Let clients migrate over to QUERY on their own timeline, instead of forcing a switch.

Nobody needs to rip out a working POST search endpoint tomorrow. This is a "start advertising it, let adoption happen naturally" kind of rollout, not a "migrate everything this sprint" one.

The one-line version

HTTP just got its first new method in 16 years. QUERY gives you a way to send a complex, structured request body — like POST — while keeping the safe, repeatable, cacheable guarantees of GET. It's real, it's an official standard, and it's genuinely useful — but browsers, frameworks, and infrastructure are all still catching up, so treat it as something to watch and start testing with, not something to depend on in production just yet.

Have you run into the "GET can't hold this much data, but POST doesn't feel safe to cache" problem yourself? That's exactly the itch QUERY is trying to scratch.

How AWS CodePipeline Works: A Real CI/CD Flow (Source, Build, Deploy)

Guna SantoshDeep Srivastava — Tue, 14 Jul 2026 13:59:23 +0000

I used CodePipeline for months without really understanding it: push code, stages turn green, app updates. That was fine until something broke and the console didn't explain why, and I got tired of just guessing. So I opened a terminal and traced my own pipeline step by step, using the AWS CLI — every file, every stage, every "why does this even exist." It turned out to be a lot more interesting than the console picture makes it look.

Here's what I found, with the real commands and the real output (with private details removed). If you've ever wondered what actually happens between "code pushed" and "app updated," this is it.

How the pipeline actually wakes up

First question: does CodePipeline keep checking CodeCommit for changes, or does something tell it the moment a change happens? I checked the pipeline settings to find out:

aws codepipeline get-pipeline --name my-app --profile my-profile --region us-west-2

"triggerType": "CloudWatchEvent",
"PollForSourceChanges": "false"

That answers it:

PollForSourceChanges: false means it's not checking on a timer.
A separate CloudWatch Events rule sits in the background, watching for pushes to that branch.
The moment a push happens, that rule starts the pipeline right away — not "sometime in the next minute or two."

What "Source" actually produces

Here's something I hadn't thought about before: the Source stage doesn't give Build a live link to your repo. It packs up a snapshot instead.

"configuration": {
    "BranchName": "qa",
    "OutputArtifactFormat": "CODE_ZIP",
    "RepositoryName": "my-app"
}

CODE_ZIP means CodePipeline takes the whole repo at that commit and turns it into one plain zip file.
No .git folder, no history — just the files as they were at that exact moment.
There's another option, CODEBUILD_CLONE_REF, that does a real git clone instead, in case your build ever needs actual git history.

Where that zip actually goes

Source, Build, and Deploy each run in their own separate, temporary space — they don't share files directly. So the zip needs one shared place to sit, and that's an S3 bucket that CodePipeline manages for the whole pipeline:

"artifactStore": {
    "type": "S3",
    "location": "codepipeline-us-west-2-<ACCOUNT_ID>"
}

This one bucket holds files for every stage of the pipeline — it's not tied to one specific file. The exact file name (the "key") is different every time the pipeline runs.

Proving the zip is real

I didn't want to just take this on faith, so I looked at the real file:

aws s3api head-object --bucket codepipeline-us-west-2-<ACCOUNT_ID> --key "my-app/SourceArti/<key>" --profile my-profile --region us-west-2

{
    "ContentLength": 98230361,
    "ContentType": "application/zip",
    "ServerSideEncryption": "aws:kms"
}

What this confirms:

A real zip file, about 98 MB — the whole repo, nothing left out.
Locked with KMS encryption while it sits in storage.
These files delete themselves after a set amount of time — they're not meant to stay forever, just handed off between stages and cleaned up afterward.

Finding the right artifact, not an old one

S3 doesn't know which file is "the latest one in this folder" — only CodePipeline actually keeps track of that. So if something's broken, don't just guess by browsing S3 folders. Ask the pipeline first:

aws codepipeline get-pipeline-state --name my-app --profile my-profile --region us-west-2

"currentRevision": { "revisionId": "<commit-hash>" },
"latestExecution": { "status": "Succeeded" },
"pipelineExecutionId": "<execution-id>"

currentRevision.revisionId is the real commit hash that was pulled. Copy that value, then use list-action-executions with the matching pipelineExecutionId to find the exact S3 file for that specific run.

Build: how it knows what to work on

Now, the Build stage. It doesn't just magically know where the code is — the pipeline settings tell it directly:

"configuration": {
    "ProjectName": "my-app"
},
"inputArtifacts": [{ "name": "SourceArtifact" }]

SourceArtifact is just a name tag. CodePipeline connects that name to the real bucket and file it just created in the Source stage — Build never has to know the real path itself.

What it actually runs on

"environment": {
    "type": "LINUX_CONTAINER",
    "image": "aws/codebuild/amazonlinux-x86_64-standard:6.0",
    "computeType": "BUILD_GENERAL1_MEDIUM"
},
"environmentVariables": [
    { "name": "PROFILE_NAME", "value": "qa" },
    { "name": "HOST_ENTRY",   "value": "<internal-host>:<internal-ip>" },
    { "name": "TAG_VERSION",  "value": "latest_qa" }
]

What happens every single build:

A brand-new Amazon Linux container is created — no leftover cache, nothing saved from the last run.
These environment variables (PROFILE_NAME, HOST_ENTRY, TAG_VERSION) are already set inside it for buildspec.yml to use.
Before any of your commands even run, CodeBuild automatically downloads and unzips SourceArtifact into the container's working folder.

That last point is why your pom.xml, source files, Dockerfile, and everything else are just "there" the moment the build starts — nobody has to unzip anything by hand.

Walking through the buildspec, step by step

install phase — sets up the runtime:

runtime-versions:
  java: corretto17

pre_build phase — logging in, before anything gets built:

- aws ecr get-login-password | docker login --username AWS --password-stdin <account-id>.dkr.ecr.us-west-2.amazonaws.com
- export CODEARTIFACT_AUTH_TOKEN=$(aws codeartifact get-authorization-token --domain my-codeartifact-domain ...)

Line 1 logs Docker into ECR using a password that only works for a short time. This is what makes the later docker push command actually work.
Line 2 gets a token so Maven can download private dependencies later, using settings.xml.
One tip: don't print env in a real pipeline. It's handy for debugging on your own computer, but it prints every environment variable — including ones you didn't mean to share — straight into build logs your whole team can read.

build phase — the actual compile:

- mvn -s settings.xml package -DskipTests=true

Compiles the Spring Boot project and packs it into a .jar file.

post_build phase — this is where it gets interesting:

- docker build -t my-app:${TAG_VERSION} .
- docker tag my-app:${TAG_VERSION} <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}
- docker push <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}

Line 1 builds the image inside the CodeBuild container.
Line 2 gives it a second label pointing at the ECR address.
Line 3 uploads it — this is the exact moment the image stops being "a temporary file that's about to disappear" and becomes a real, permanent file that sticks around.

Proof it landed:

aws ecr describe-images --repository-name my-app --profile my-profile --region us-west-2

{
    "imageDigest": "sha256:<digest>",
    "imagePushedAt": "2026-07-13T18:24:55+05:30"
}

The part that actually surprised me

Here's the one thing that made this whole exercise worth doing: Build creates two completely separate outputs, and they don't go to the same place.

The Docker image — the actual application, ~290 MB in my case — goes to ECR.
A tiny zip — just deploy scripts and a small deployment-env-vars file, about 2.35 KB total — goes to S3, in a folder CodePipeline labels BuildArtifact.

Laid out side by side, the size gap is what makes it click:

What	Goes where	Size
Docker image	Container registry (ECR)	~290 MB
Deploy scripts + tag reference	S3 (`BuildArtifact`)	~2-3 KB

These aren't two copies of the same thing — they're not even close in size. The small S3 zip only exists so CodePipeline can hand Deploy one simple instruction: "here's the image tag to go get from ECR." That's because CodePipeline can only pass files forward through S3, never directly through ECR. Your actual application never touches that small handoff file at all.

If you want to see this yourself: open S3, find your pipeline's artifact bucket, look inside the BuildArtifact folder, download the (tiny) zip, and unzip it locally. You'll find things like appspec.yml, a couple of shell scripts, and an imagedefinitions.json — nothing that looks like your actual application code, because it was never meant to be in there.

Stage 3 — Deploy

This is the part that made the whole "small zip vs. big image" split actually make sense to me. Deploy is different from Source and Build in one big way: it doesn't create a temporary container somewhere in AWS. It runs directly on your actual EC2 server, using the CodeDeploy agent that's already installed and running there.

The first thing the agent does is read appspec.yml — the file that was inside that tiny zip the whole time — to find out which script to run, and when:

version: 0.0
os: linux
hooks:
  ApplicationStop:
    - location: stop_container.sh
      timeout: 300
  AfterInstall:
    - location: start_container.sh
      timeout: 300

CodeDeploy always follows the same set order of steps on the server, and appspec.yml just connects your scripts to the steps you care about:

ApplicationStop → stop_container.sh — runs before anything new gets installed. Its job is simple: stop and remove whatever container is already running under this app's name, so the port is free and there's no clash when the new one starts.
AfterInstall → start_container.sh — this is where most of the real work happens. It's also where that deployment-env-vars file — the one that's been sitting quietly in the small zip since the Build stage — finally gets used.

Roughly, here's what start_container.sh does:

# read the image tag that Build decided on
source deployment-env-vars

# pull that exact image from ECR
docker pull <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}

# start it with the right port mapping, env vars, and volumes
docker run -d \
  --name my-app \
  -p 8080:8080 \
  --env-file app.env \
  -v /opt/my-app/logs:/app/logs \
  <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}

And that's the moment everything comes together. Remember that "just instructions" file from the Build stage — the one that seemed too small to matter next to a 290 MB image? This is what it was for, the whole time:

It never carried any real weight itself.
It just told this script which tag to go get.
The image had already been sitting in ECR since the Build stage finished.
Deploy's only job is to tell the server to go grab it and run it.

It's a small thing, but it changed how I think about the whole pipeline: Source and Build are about creating files and putting them in the right place. Deploy isn't really "installing" anything in the usual sense — it's just giving the server one clear instruction and stepping out of the way.

The short version, if you just want the summary

Source starts the moment you push (no waiting, no timer), packs the exact commit into a zip with no git history, and drops it into a shared S3 bucket under a brand-new name every time.
Build picks that zip up on its own, compiles the code, and builds a Docker image.
Build's output splits in two: the real app goes to ECR, and a tiny instruction file goes to S3 just to tell Deploy which image tag to grab.
Deploy runs right on the EC2 server itself, reads that small file to find the right tag, stops whatever's currently running, pulls the new image from ECR, and starts it back up.

Have you ever traced your own pipeline's files like this, or do you just trust the console screen for it? I expected this to be boring, and instead I came out understanding what I'm actually running, much better than before.

Service-to-Service Communication in Microservices: What Every Developer Should Know

Guna SantoshDeep Srivastava — Mon, 13 Jul 2026 09:02:51 +0000

I still remember the first time a junior dev I was mentoring asked me, "why did the order service just... hang for 30 seconds and then crash the whole checkout flow?" The answer had nothing to do with their code being wrong. It had everything to do with how their service was talking to another service — and nobody had ever actually taught them that part.

That's the gap this post is trying to close. Not "what is a microservice" — you already know that. This is about the part that trips up almost everyone the first time they split a monolith into services: how do these things actually talk to each other, and what breaks when they do?

We'll go through this using Spring Boot, since that's what most Java shops are running, but the concepts carry over regardless of stack.

The thing that changes the moment you split a monolith

In a monolith, calling another module is just a method call. It's fast, it's reliable, and if something goes wrong, you get a stack trace pointing at the exact line.

The moment that "module" becomes a separate service running somewhere else, that method call becomes a network call. And a network call can fail in ways a method call never does: the other service could be slow, temporarily down, overloaded, or reachable but taking 45 seconds to respond because its database is having a bad day. Your code needs to handle all of that, and most tutorials skip straight past it to show you the happy path.

So let's not skip it.

Synchronous communication: when you need the answer right now

This is the "call and wait" pattern — Service A calls Service B and blocks until it gets a response. Good for things like "check if this user is allowed to do this," where you genuinely can't proceed without the answer.

RestTemplate — you'll see this in a lot of existing codebases. It's not formally deprecated, but the class Javadoc itself says it's in maintenance mode and won't get new features. Worth knowing how to read, not worth starting a new project with.

RestTemplate restTemplate = new RestTemplate();
UserDto user = restTemplate.getForObject(
    "http://user-service/users/{id}", UserDto.class, userId);

If you specifically want a modern synchronous client without pulling in WebFlux, Spring Boot 3.2+ also ships RestClient — same fluent style as WebClient below, but blocking by default. Worth a look if WebClient feels like overkill for a non-reactive app.

WebClient — the modern reactive replacement, and it works fine even if you're not doing reactive programming elsewhere in your app. You can call .block() if you just want a plain synchronous result. Full options are in the Spring Framework WebClient reference, including the example code for things like timeouts and filters.

WebClient client = WebClient.create("http://user-service");

UserDto user = client.get()
    .uri("/users/{id}", userId)
    .retrieve()
    .bodyToMono(UserDto.class)
    .block();

OpenFeign — if you're in a Spring Cloud microservices setup, this is probably what you actually want. You declare an interface, Feign generates the HTTP client for you, and it reads like a normal method call again. Full setup and config options are in the Spring Cloud OpenFeign reference docs.

@FeignClient(name = "user-service")
public interface UserClient {
    @GetMapping("/users/{id}")
    UserDto getUser(@PathVariable("id") Long id);
}

Then you just inject UserClient and call userClient.getUser(id) like it's a local bean. This is usually the nicest developer experience of the three, which is part of why it's so widely used in Spring Cloud shops.

Worth knowing if you're starting something new: Spring Cloud OpenFeign itself now says it's feature-complete and points people toward Spring's own native declarative clients (@HttpExchange + @ImportHttpServices), introduced in Spring Framework 7. Same declarative-interface idea as Feign, just built into core Spring instead of a separate dependency. Spring's own writeup on it is here if you want the example code. Feign isn't going anywhere soon, but if you're picking a client for a brand-new project, it's worth a look before you default to Feign out of habit.

Asynchronous communication: when you don't need the answer right now

Not everything needs an immediate response. "Send a confirmation email after checkout" doesn't need to block the checkout request — it just needs to eventually happen. This is where message brokers come in: Service A publishes an event, Service B picks it up whenever it's ready, and the two services never have to be online at the same moment.

Kafka, with Spring Kafka (full reference and runnable examples here):

// Producer
@Autowired
private KafkaTemplate<String, OrderEvent> kafkaTemplate;

public void publishOrderCreated(OrderEvent event) {
    kafkaTemplate.send("order-events", event);
}

// Consumer, in a different service entirely
@KafkaListener(topics = "order-events", groupId = "email-service")
public void handleOrderCreated(OrderEvent event) {
    emailService.sendConfirmation(event.getOrderId());
}

RabbitMQ, with Spring AMQP (reference docs and more listener examples here), if you want more routing flexibility than Kafka's topic model gives you:

@RabbitListener(queues = "order.created.queue")
public void handleOrderCreated(OrderEvent event) {
    emailService.sendConfirmation(event.getOrderId());
}

The real decision isn't "Kafka vs RabbitMQ" — that's a second-order question. The first question is sync vs async, and that comes down to one thing: does the caller need the result before it can continue? If yes, sync. If no, you're just adding latency and coupling for no reason by making it synchronous.

The part beginners skip and seniors get burned by anyway

This is the section that actually matters more than picking a client library.

Timeouts. If you don't set one explicitly, you may be relying on a default that's way too generous — or in some client setups, no timeout at all. A slow downstream service without a timeout on the caller side doesn't just slow you down, it can exhaust your thread pool and take down services that have nothing to do with the original problem.

WebClient client = WebClient.builder()
    .baseUrl("http://user-service")
    .clientConnector(new ReactorClientHttpConnector(
        HttpClient.create().responseTimeout(Duration.ofSeconds(3))))
    .build();

Retries. Sounds simple until you ask: is this call safe to retry? A GET usually is. A POST that charges a credit card is not — unless you've made it idempotent (idempotency keys are the usual fix). Blindly wrapping every call in a retry loop is how you get duplicate charges, not resilience.

Circuit breakers. When a downstream service is genuinely down, retrying just piles more load onto something that's already struggling — and it makes the caller's own response times terrible while it keeps trying. Resilience4j (official docs and full config reference here) handles this cleanly in Spring Boot:

@CircuitBreaker(name = "userService", fallbackMethod = "fallbackUser")
public UserDto getUser(Long id) {
    return userClient.getUser(id);
}

public UserDto fallbackUser(Long id, Throwable t) {
    return UserDto.guest();
}

Once the failure rate crosses a threshold, the circuit "opens," calls fail fast without even hitting the network, and the fallback kicks in instead. That one annotation is doing a lot of work most teams don't add until after their first real outage.

Finding each other in the first place

One more piece worth knowing: in a real deployment, service instances scale up and down and their addresses change. Hardcoding http://user-service-host:8080 doesn't survive that. Spring Cloud's usual answer is a discovery service like Eureka, paired with Spring Cloud LoadBalancer — services register themselves on startup, and callers ask the registry "where's user-service right now?" instead of hardcoding an address. If you noticed http://user-service in the Feign and WebClient examples above with no port or IP — that's this in action, resolved by the load balancer at call time.

Quick decision guide

Situation	Reach for
You need the result before you can continue	Synchronous (WebClient or Feign)
The action can happen "eventually"	Asynchronous (Kafka or RabbitMQ)
Multiple services need to react to the same event	Asynchronous, pub/sub
Calling a flaky or slow external dependency	Synchronous + circuit breaker, always
Instance addresses change as you scale	Service discovery (Eureka), not hardcoded URLs

What I've actually seen go wrong in practice

The bug that gets people almost every time isn't a missing feature — it's a missing timeout. Someone calls a downstream service, doesn't set an explicit timeout, everything works fine in dev because the downstream service is fast and local, and then in production, under real load, one slow dependency quietly takes the whole request chain down with it. It's boring, it's not a "clever" bug, and it's also the single most common root cause I've run into in real incident reviews.

If you take away one thing from this post: don't add a client library and call it done. Set a timeout. Decide, explicitly, whether each call is safe to retry. Those two habits alone prevent most of the outages I've seen traced back to service-to-service calls.

What's the worst service-to-service incident you've personally debugged? I'm curious whether it was a timeout, a retry storm, or something weirder — genuinely feels like everyone in this field has one story.

AWS CodePipeline Tutorial: Deploy to EC2 with CodeCommit, CodeBuild & CodeDeploy

Guna SantoshDeep Srivastava — Mon, 13 Jul 2026 07:35:29 +0000

This is a step-by-step AWS CodePipeline tutorial for anyone who needs to deploy to EC2 using CodeCommit, CodeBuild, and CodeDeploy together. I set this exact pipeline up recently and kept notes as I went, so this is the walkthrough I wish I'd had — console clicks and all.

The pipeline covers the standard flow: pull source from CodeCommit, build it with CodeBuild, and deploy straight to an EC2 instance with CodeDeploy. No test stage, no load balancer — just the core CodePipeline setup most small-to-mid apps actually need to get from git push to a running EC2 instance.

If you want to cross-check any step against the source, AWS's own walkthrough for this exact flow is here: Tutorial: Create a simple pipeline (CodeCommit repository).

Before you start

Make sure you've got:

Console access with permissions for CodePipeline, CodeCommit, CodeBuild, and CodeDeploy
Your source code already pushed to a CodeCommit repo
Three IAM service roles created ahead of time: one for CodePipeline, one for CodeBuild, one for CodeDeploy (EC2)
A target EC2 instance with the CodeDeploy agent installed and an IAM instance profile attached
A buildspec.yml in the root of your repo

If any of those are missing, sort them out first — the pipeline wizard will let you create some things inline, but the IAM roles are much easier to set up beforehand.

Step 1: Confirm your CodeCommit repo exists

Nothing fancy here — just make sure the repository you want to build from is already in CodeCommit with your code pushed to the branch you plan to deploy from.

Step 2: Open CodePipeline and start a new pipeline

From the AWS Console, go to CodePipeline → Create pipeline.

Step 3: Choose "Build custom pipeline"

This gives you full control over each stage instead of using one of the templated flows.

Step 4: Configure the pipeline basics

Setting	Value
Pipeline name	whatever makes sense for your app/environment
Execution mode	Superseded
Service role	Existing service role
Role ARN	`arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YourCodePipelineServiceRole>`
Advanced settings	Defaults are fine to start

Step 5: Add the source stage

Setting	Value
Source provider	AWS CodeCommit
Repository name	your repo
Branch name	whichever branch this pipeline should track (e.g. `main`, `qa`, `staging`)
Other settings	Defaults

Step 6: Setting up the CodeBuild stage

Set Build provider to AWS CodeBuild.

If you already have a CodeBuild project for this app, just search for it and select it. If not, here's what a fresh project looks like (full console walkthrough here):

Setting	Value
Project name	name it after your app
Environment – OS	Amazon Linux
Environment – Runtime	Standard
Environment – Image	`aws/codebuild/standard:6.0`
Service role	Existing service role
Role ARN	`arn:aws:iam::<YOUR_ACCOUNT_ID>:role/service-role/<YourCodeBuildServiceRole>`
Buildspec	Use a buildspec file
Batch configuration / Logs	Defaults

After creating it, go back and select it from the project list — the wizard doesn't always auto-select a project you just created.

Optional environment variables, if your build needs them:

Name	Example value
`PROFILE_NAME`	`qa`
`HOST_ENTRY`	`<your-ec2-hostname>:<your-ec2-private-ip>`

Leave build type as Single build unless you specifically need batch builds.

Step 7: Skip the test stage

Unless you're wiring up an automated test stage separately, you can skip this one entirely.

Step 8: Setting up the CodeDeploy stage for EC2 deployment

Setting	Value
Deploy provider	AWS CodeDeploy
Input artifacts	BuildArtifact
Application name	select existing, or create new

If you don't have a CodeDeploy application yet:

Go to CodeDeploy → Applications → Create application
Set Compute platform to EC2/On-Premises
Create a deployment group with:

Setting	Value
Service role ARN	`arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YourEC2CodeDeployRole>`
Deployment type	Default (in-place, unless you need blue/green)
Environment configuration	Amazon EC2 instances
Instance name/tag	whatever tag identifies your target instance(s)
Load balancer	leave unchecked if you're not using one

Step 9: Review and create

Double check every stage, then hit Create pipeline. It'll kick off an initial run immediately.

A few things I'd flag for anyone doing this

Double-check your IAM trust relationships before you start. Half the "pipeline failed" errors I hit came down to a service role missing a trust policy, not the pipeline config itself.
Never commit real account IDs, role ARNs, or internal hostnames into a public repo or a public writeup. It's an easy habit to slip into when you're copying from your own working setup — always swap in placeholders before sharing.
Validate your buildspec.yml locally (or with aws codebuild start-build first) before wiring it into a full pipeline. Debugging a broken buildspec through the pipeline UI is slower than catching it upfront.
If you're running this across multiple environments (dev/QA/prod), keep the environment-specific values — account IDs, hostnames, role ARNs — in a separate config reference rather than hardcoding them per pipeline. Makes it much easier to replicate later.

That's the whole flow. Happy to answer questions if anyone's stuck on a specific stage.

Cursor Just Became Part of SpaceX — Here's What Developers Should Actually Watch For

Guna SantoshDeep Srivastava — Mon, 13 Jul 2026 07:08:24 +0000

I saw the headline last month and honestly scrolled past it — another AI company acquisition, who cares. But this one's actually worth a second look if you write code for a living.

Cursor's parent company, Anysphere, is getting absorbed into SpaceX. $60 billion, all stock, deal reported by CNBC here. Most of what's been written about it is finance-desk stuff — IPO timing, share structure, how fast the revenue curve went up and to the right. Nobody's really talked about what it means for the tool itself, which is the part I actually care about.

What happened, quickly

SpaceX had an option to buy Anysphere sitting around since April, and in June they used it. Once the deal closes (expected sometime this quarter, still pending regulatory approval), Cursor becomes part of the same company that owns xAI and Grok. So Elon's AI stack, which never really had a coding product of its own, suddenly has one — same category as Claude Code from Anthropic or Codex from OpenAI.

On its own that's just an acquisition. Companies buy companies. But there's a piece of this that actually changes the product, not just the org chart.

The part that actually matters

Cursor's whole thing, since it launched, was that it didn't care which model you used. Claude, GPT, Gemini, its own Composer model — you picked whatever worked for the task and Cursor got out of the way. That's a big reason a lot of teams picked it over something tied to a single vendor.

Once your editor's parent company also owns a frontier model, "we don't care which model you use" gets a lot harder to actually believe, even if nothing changes on day one. There's a quote from an analyst at Futurum Group that stuck with me — he said moving inside a model vendor turns a model-agnostic layer into a captive one. That's the whole risk in one sentence. Enterprise teams are already treating Cursor less like a neutral tool and more like a bet on one company.

I'm not saying Cursor gets worse next week. I'm saying if you picked it because it let you shop around, that reason just got shakier.

What I'd actually keep an eye on

Not going to pretend I have a crystal ball here, but if I were running Cursor day to day, this is what I'd watch instead of doom-scrolling about it:

Whether the model picker starts quietly defaulting to Grok/Composer instead of staying neutral. Whether the pricing gap between first-party and third-party models (which already showed up this month) gets wider once the deal actually closes. Whether the data/training policy changes once Cursor sits under new ownership — worth a second read once that happens instead of assuming it's the same as before. And if your company has an enterprise contract with Cursor, it's probably worth an email to whoever owns that relationship, just to ask what happens to it.

None of that is a reason to switch tools today. It's a reason to actually read the changelog for once instead of clicking past it.

Where I land on this

I don't think Cursor is doomed, and I'm not telling anyone to jump to Claude Code or Codex out of pure caution. Tools get bought all the time and plenty of them keep getting better afterward. But "who owns the company behind my editor" is now a real factor in choosing a coding tool, in a way it wasn't six months ago. That's new, and I don't think enough people are talking about it.

I mostly live in VS Code with Copilot day to day rather than Cursor, so I'm watching this one from the outside — but I'm curious how it looks from the inside.

If you're actually running Cursor right now: does any of this change what you're doing, or does it not matter at all to you? Curious if I'm overthinking a corporate acquisition that has nothing to do with the editor you open every morning.

angular

Guna SantoshDeep Srivastava — Tue, 24 Jun 2025 06:23:19 +0000

DEV Community: Guna SantoshDeep Srivastava

JVM Architecture Explained: The Heart of Java (Class Loader, Runtime Data & Execution Engine)

1. Class Loader Subsystem — getting your code into memory

2. Runtime Data Areas — where everything actually lives in memory

3. Execution Engine — actually running the bytecode

4. JNI (Java Native Interface) — the bridge to C/C++

5. Native Method Libraries

The complete flow, start to finish

Class loader hierarchy: parent delegation

Quick answers, if this comes up in an interview

The short version

JDK vs JRE vs JVM: The JRE Download Doesn't Exist Anymore

The three pieces, in plain terms

How a Java program actually gets from code to output

A simple way to picture it

Side-by-side comparison

The part most tutorials get outdated on

Where each one is actually used, in practice

Quick answers, if this comes up in an interview

The short version

Further reading

Java Wasn't Built by One Person, and Sun Doesn't Own It Anymore

The people behind Java (not just Gosling)

The 16 features that actually define Java

Secure — what this actually protects against

Dynamic — the one people usually get wrong

Distributed — why this used to be a bigger deal than it sounds

Write once, run anywhere — the quick version

Quick answers, if this comes up in an interview

The short version

Further reading

Java Evolution: LTS vs Non-LTS, and What's Actually Current Right Now

How Java got here: a quick timeline

LTS vs. Non-LTS: the difference that actually matters

Current LTS versions

What's actually new in the versions people use today

Correcting the record: Java 26 already shipped

LTS vs. Non-LTS, side by side

How to check your Java version

Going deeper: why this is actually a licensing decision, not just a technical one

Quick answers, if this comes up in an interview

The short version

Further reading

Java Was Built for TV Boxes, Not the Web — And It Almost Failed

Before Java: why software development was a mess

How Java actually started

What Sun Microsystems actually wanted

How "write once, run anywhere" actually works

The part that goes a bit deeper: how the JVM makes this both secure and fast

Main reasons Java was created, side by side

Quick answers, if this comes up in an interview

The short version

Further reading

Java Collection Framework: The Interview Answer That Actually Impresses Interviewers

What it actually is

The shape of the framework

List — ordered, and duplicates are fine

Set — no duplicates allowed

Queue — first in, first out

Map — key to value, and it's not part of Collection

All four, side by side

A memory trick that actually sticks

Quick answers, if you're prepping for an interview right now

The one-line interview answer

HTTP Got a New Method After 16 Years — Meet QUERY (RFC 10008)

The problem QUERY is solving

What QUERY actually is

Where this actually helps

What's not ready yet

How a client actually discovers QUERY is supported

How to actually roll this out

The one-line version

How AWS CodePipeline Works: A Real CI/CD Flow (Source, Build, Deploy)

How the pipeline actually wakes up

What "Source" actually produces

Where that zip actually goes

Proving the zip is real

Finding the right artifact, not an old one

Build: how it knows what to work on

What it actually runs on