DEV Community: Dhairya Gemini

My Journey into Java Enterprise Development: From Java Fundamentals to Web Applications

Dhairya Gemini — Sat, 03 Oct 2026 14:38:21 +0000

Over the past few weeks, I’ve been taking a deeper dive into Java backend and enterprise development.

Instead of only learning Java syntax and programming concepts, I wanted to understand what happens when Java is used to build real web applications—from handling HTTP requests to connecting applications with databases, managing dependencies, and writing automated tests.

During this learning journey, I explored Eclipse, Java EE, Maven, Gradle, JDBC, Servlets, JSP, and JUnit.

Here’s what I learned from each of them and how they connect together.

Eclipse — My Development Environment

I started working with Eclipse IDE, which gave me a better understanding of how Java web projects are structured and managed.

I worked with:

Java projects
Web application projects
Project configuration
Debugging
Server integration
Managing source files and dependencies

Using an IDE isn't just about writing code faster. It also helps understand how a larger Java application is organized.

Java EE — Understanding Enterprise Java

After working with core Java, I started exploring Java EE (Enterprise Edition) and the concepts behind Java-based web applications.

This helped me understand how Java can be used beyond standalone programs to build applications that communicate with users, servers, databases, and other components.

I started seeing Java not just as a programming language, but as part of a complete backend ecosystem.

Maven — Managing a Java Project

One of the most useful things I learned was Maven.

Before Maven, adding and managing libraries manually can become difficult as a project grows.

Maven introduced me to concepts such as:

"pom.xml"
Dependencies
Plugins
Project lifecycle
Build management
Dependency management

It made me understand how professional Java projects manage external libraries and builds.

Gradle — Another Approach to Build Automation

After Maven, I explored Gradle.

Gradle helped me understand another approach to build automation and dependency management.

Comparing Maven and Gradle also taught me something important: there isn't always one tool for every situation. Understanding the concepts behind build systems is more valuable than simply memorizing commands.

JDBC — Connecting Java with Databases

Then came JDBC (Java Database Connectivity).

This was an important step because it connected my Java code with databases.

I learned about:

Database connections
SQL queries
"Connection"
"PreparedStatement"
"ResultSet"
CRUD operations
Exception handling
Closing database resources

JDBC helped me understand what actually happens when a backend application communicates with a database.

Servlets — Understanding HTTP Requests

Learning Servlets was one of the most interesting parts of this journey.

Servlets helped me understand how a Java web application handles HTTP requests and responses.

I learned about concepts such as:

"HttpServlet"
"doGet()"
"doPost()"
"HttpServletRequest"
"HttpServletResponse"
Request parameters
Response handling
Servlet lifecycle

This made the connection between the browser and backend much clearer to me.

A request comes from the client → the server processes it → application logic runs → a response is returned.

That simple flow helped me understand backend development much better.

JSP — Dynamic Web Pages

I also explored JSP (JavaServer Pages).

JSP showed me how server-side Java applications can generate dynamic web content.

While learning JSP, I started understanding how frontend pages can interact with backend logic and how server-side rendering works.

It also helped me understand why separating presentation, business logic, and data access is important when building maintainable applications.

JUnit — Testing My Code

Finally, I learned JUnit for unit testing.

This changed the way I think about writing code.

Writing code that works once is one thing.

Writing code that can be tested repeatedly and reliably is another.

With JUnit, I explored:

Test cases
Assertions
Test methods
Testing individual units of code
Identifying failures automatically

Testing helped me understand that development isn't only about creating features—it is also about making sure those features continue to work.

How Everything Connects

The most valuable part of this learning journey wasn't learning these technologies separately.

It was understanding how they can work together.

A simplified Java web application can look something like this:

Client → Servlet → Business Logic → JDBC → Database

And tools such as Maven or Gradle help manage the project and its dependencies, while JUnit helps test the application.

Eclipse provides the development environment where I can build, debug, and manage the project.

Understanding this bigger picture made the individual technologies much easier to understand.

What I Learned Beyond the Technologies

The biggest lesson wasn't a specific framework or command.

It was learning how different components of backend development fit together.

I learned that:

«Learning backend development isn't just about learning a programming language. It's about understanding how applications communicate, store data, manage dependencies, handle requests, and verify that the code works.»

I also became more comfortable reading documentation, debugging errors, understanding project structures, and figuring out why something isn't working instead of simply searching for a solution and copying it.

What's Next?

This is not the end of my Java learning journey.

My next focus is to go deeper into backend development and start building more complete projects using the concepts I've learned.

There is still a lot to learn—especially modern Java backend frameworks, REST APIs, security, database design, deployment, and scalable application architecture.

But these technologies gave me a strong foundation for understanding what happens behind a Java web application.

From Java fundamentals → Java web development → databases → testing → backend projects.

One step at a time.

Final Thoughts

Learning Eclipse, Java EE, Maven, Gradle, JDBC, Servlets, JSP, and JUnit has been a valuable part of my journey as a Java developer.

Each technology taught me something different, but together they helped me see the bigger picture of backend development.

I'm still learning, still building, and still debugging.

And honestly, that's one of the most interesting parts of software development.

Build. Learn. Debug. Improve. Repeat.

What Really Happens When You Run a Java Program? A Deep Dive from .java to JVM Execution ❓️❓️

Dhairya Gemini — Sun, 09 Aug 2026 09:42:44 +0000

What Really Happens When You Run a Java Program? A Deep Dive from ".java" to JVM Execution

When we write a Java program, it looks deceptively simple:

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

We save the file, run:

javac Main.java
java Main

and get:

Hello, World!

But what actually happens between these two commands?

Java doesn't directly execute the ".java" file.

Instead, the program goes through several stages involving the Java compiler, bytecode, class loader, JVM, interpreter, JIT compiler, and runtime memory.

Let's break the entire process down.

Writing the Java Source Code

First, we write a Java source file:

public class Main {
public static void main(String[] args) {
int a = 10;
int b = 20;

    System.out.println(a + b);
}

}

The file is saved as:

Main.java

At this stage, it is simply human-readable source code.

The computer cannot execute this source code directly.

The Java Compiler Enters the Picture

When we run:

javac Main.java

the Java compiler ("javac") analyzes our source code.

It checks things such as:

Syntax
Data types
Variable declarations
Method calls
Class structure
Access modifiers
Other compile-time rules

If everything is correct, the compiler generates:

Main.class

This is where Java becomes interesting.

Java Doesn't Compile Directly to Machine Code

Languages such as C and C++ commonly compile source code into native machine code for a particular architecture.

Java takes a different approach.

The Java compiler converts:

Java Source Code
↓
javac
↓
Bytecode
↓
Main.class

The ".class" file contains Java bytecode.

For example, conceptually, our Java code might contain bytecode instructions such as:

iload
iadd
invokevirtual
return

Bytecode is not native machine code.

It is an intermediate instruction set designed to be executed by the Java Virtual Machine (JVM).

Why Does Java Use Bytecode?

This is one of the most important ideas behind Java's portability.

Suppose you compile a Java program on Windows.

The resulting ".class" file can potentially run on:

Windows
Linux
macOS
Other platforms with a compatible JVM

The basic idea is:

         Java Source
              ↓
           javac
              ↓
           Bytecode
              ↓
   ┌──────────┼──────────┐
   ↓          ↓          ↓
 JVM        JVM        JVM

Windows Linux macOS

The JVM handles the platform-specific execution.

This is the foundation behind Java's famous:

«Write Once, Run Anywhere»

The JVM Takes Over

When we execute:

java Main

the JVM starts.

But the JVM doesn't simply open the ".class" file and immediately execute everything.

Several components become involved.

A simplified pipeline looks like this:

Main.class
↓
Class Loader
↓
Bytecode Verification
↓
Runtime Data Areas
↓
Execution Engine
↓
Interpreter / JIT Compiler
↓
Machine Code
↓
CPU

Let's understand each part.

Class Loader

The Class Loader is responsible for loading class information into JVM memory.

When the JVM needs the "Main" class, the Class Loader finds and loads it.

Java's class-loading process is commonly discussed in three major phases:

The JVM finds the class and loads its binary representation.

Linking

Linking includes:

Verification
Preparation
Resolution

Initialization

Static fields and static initialization blocks are initialized when required.

For example:

class Example {

static int number = 100;

static {
    System.out.println("Class initialized");
}

}

The JVM performs class initialization according to Java's initialization rules.

Bytecode Verification

Before executing bytecode, the JVM performs verification.

The purpose is to ensure that the bytecode follows JVM constraints.

This helps prevent invalid operations and contributes to Java's runtime safety model.

Conceptually:

.class file
↓
Bytecode Verifier
↓
Valid?
↙ ↘
Yes No
↓ ↓
Execute Error

This is one reason Java's execution environment is more controlled than simply executing arbitrary machine instructions.

JVM Runtime Memory

The JVM manages several runtime data areas.

Some of the most important ones are:

Heap
Java Virtual Machine Stacks
Method Area
PC Register
Native Method Stacks

Let's focus on the most commonly discussed ones.

Heap

Objects are generally allocated on the heap.

For example:

Student student = new Student();

The object created by:

new Student()

is allocated in heap memory.

The variable:

student

holds a reference to that object.

Conceptually:

Stack

student ──────────────┐
↓
Heap
┌───────────┐
│ Student │
│ object │
└───────────┘

The JVM's garbage collector can later reclaim memory occupied by objects that are no longer reachable.

Stack Memory

Each thread has its own JVM stack.

When a method is called, a new stack frame is created.

Consider:

public static void main(String[] args) {
calculate();
}

static void calculate() {
int x = 10;
int y = 20;
int result = x + y;
}

Conceptually:

JVM Stack

┌──────────────────┐
│ calculate() │
│ x = 10 │
│ y = 20 │
│ result = 30 │
├──────────────────┤
│ main() │
│ args │
└──────────────────┘

When "calculate()" finishes, its stack frame is removed.

This is one reason method calls have a structured lifetime.

The Execution Engine

After the classes are loaded and verified, the JVM needs to execute the bytecode.

This is handled by the Execution Engine.

Two important mechanisms are:

Interpreter

The interpreter executes bytecode instructions.

Conceptually:

Bytecode
↓
Interpreter
↓
Instruction
↓
Instruction
↓
Instruction

This allows code to start executing without compiling the entire application into native machine code first.

But there is a performance problem.

Interpreting the same instructions repeatedly can be expensive.

That's where JIT enters.

JIT Compilation

JIT stands for:

Just-In-Time compilation

The JVM can identify frequently executed code and compile it into optimized native machine code.

For example:

for (int i = 0; i < 1_000_000; i++) {
calculate();
}

If certain code becomes "hot", the JVM can optimize it.

Conceptually:

Bytecode
↓
Interpreter
↓
Frequently executed code
↓
JIT Compiler
↓
Native Machine Code
↓
CPU

This is one of the major reasons modern Java applications can achieve strong runtime performance.

What Is "Hot Code"?

The JVM doesn't necessarily treat every method equally.

Some code executes once.

Other code may execute millions of times.

The JVM can monitor execution and identify frequently executed portions of the application.

These are often referred to as hot spots.

The JIT compiler can then apply optimizations to those frequently executed paths.

Possible optimizations include techniques such as:

Method inlining
Dead-code elimination
Loop optimizations
Escape analysis
Other runtime-specific optimizations

The exact behavior depends on the JVM implementation and runtime conditions.

Where Do JDK and JRE Fit?

Many Java developers memorize:

JDK
JRE
JVM

but don't understand their relationship.

A simplified model is:

JDK
└── Development Tools
├── javac
├── java
├── javadoc
└── other tools

+

Java Runtime Environment

    └── JVM

Historically, the JRE was commonly distributed as a separate concept.

Modern Java distributions don't necessarily provide a standalone JRE installation in the same way older Java versions did.

The important conceptual distinction remains:

JDK: development environment

JVM: engine that executes Java bytecode

Why Doesn't Java Just Compile Everything Before Running?

A natural question is:

«If native machine code is faster, why doesn't Java simply compile everything before execution?»

Because runtime information can be extremely valuable.

The JVM can observe the actual behavior of the running application.

For example, it may discover:

Method A → rarely executed
Method B → executed millions of times
Method C → usually receives integers of a particular type

The runtime can use this information to make optimization decisions.

This is one of the powerful ideas behind modern managed runtimes.

What Happens to "System.out.println()"?

Consider:

System.out.println("Hello");

This looks like one simple operation.

But internally, several things happen:

System
↓
out
↓
PrintStream
↓
println()
↓
Output mechanism
↓
Operating system
↓
Terminal

The important lesson is that high-level Java statements often represent multiple layers of runtime behavior.

The Complete Journey

We can now visualize the entire process:

    Main.java
        │
        ▼
    Java Compiler
      javac
        │
        ▼
    Main.class
    Java Bytecode
        │
        ▼
   Class Loader
        │
        ▼
Bytecode Verification
        │
        ▼
 JVM Runtime Areas
        │
        ▼
  Execution Engine
     /        \
    /          \

Interpreter JIT
\ /
\ /
▼ ▼
Native Machine Code
│
▼
CPU

This is the simplified mental model every Java developer should understand.

Why Understanding This Matters

You might be thinking:

«"Why should I care? Java already works."»

Understanding the JVM becomes extremely useful when you start dealing with:

Performance optimization
Memory leaks
Garbage collection
Stack overflow
"OutOfMemoryError"
Multithreading
Application profiling
Backend development
JVM tuning
Production debugging

For example, when you encounter:

java.lang.StackOverflowError

you should immediately think about stack frames and potentially excessive recursion.

When you see:

java.lang.OutOfMemoryError: Java heap space

you should start thinking about heap allocation and object retention.

Understanding the JVM turns these errors from mysterious messages into useful diagnostic signals.

Final Thoughts

Java is often described simply as:

«"A programming language."»

But Java is more than the syntax we write.

A Java application involves an entire runtime ecosystem:

Source Code
↓
Compiler
↓
Bytecode
↓
Class Loader
↓
JVM
↓
Runtime Memory
↓
Interpreter / JIT
↓
Native Code
↓
CPU

Once you understand this pipeline, many advanced Java concepts become easier to reason about.

The next time you run:

java Main

remember that you're not simply "running a Java file."

You're starting a runtime system that loads bytecode, manages memory, interprets and compiles code, performs runtime optimizations, and ultimately turns Java instructions into work performed by your CPU.

And that's where Java becomes much more interesting than just writing:

System.out.println("Hello, World!");

What should you learn next?

If you're going deeper into Java, a useful progression is:

Java OOP
Collections Framework
Exception Handling
Multithreading
JVM Architecture
Garbage Collection
Java Memory Model
JVM Performance Tuning
Spring Boot
Building production-grade backend systems

Understanding the JVM is a strong foundation for that journey.

React Virtual DOM Explained: Why React Is So Fast

Dhairya Gemini — Sat, 01 Aug 2026 10:02:19 +0000

Introduction

When I first started learning React, one question kept coming to my mind:

"Why is React considered faster than traditional JavaScript?"

Many developers answer this by saying, "Because React uses the Virtual DOM."

But what exactly is the Virtual DOM? Is it a real copy of the webpage? How does it improve performance?

In this article, I'll explain the Virtual DOM in simple terms with examples so that even beginners can understand how React updates the user interface efficiently.

What Is the DOM?

DOM stands for Document Object Model.

Whenever a browser loads an HTML page, it converts the HTML into a tree-like structure called the DOM.

For example:

Hello

Click Me

becomes

Body
├── H1
└── Button

JavaScript interacts with this DOM to update the webpage.

The Problem with the Traditional DOM

Imagine a webpage containing:

Hundreds of buttons
Thousands of list items
Complex tables
Images
Charts

If only one small piece of data changes, the browser still has to perform expensive operations to update the DOM.

Frequent DOM updates can slow down an application because manipulating the real DOM is costly.

What Is the Virtual DOM?

The Virtual DOM is a lightweight JavaScript representation of the real DOM.

Instead of immediately changing the real webpage, React first creates a virtual copy in memory.

When data changes:

React creates a new Virtual DOM.
It compares it with the previous Virtual DOM.
It finds exactly what changed.
It updates only those specific parts of the real DOM.

This makes updates much more efficient.

A Simple Example

Suppose you have:

Counter: 0

After clicking a button:

Counter: 1

React notices that only the number changed.

Instead of rebuilding the entire page, it updates only the text node.

This saves time and improves performance.

How React Finds Changes

React uses a process called Diffing.

It compares:

Old Virtual DOM

↓

New Virtual DOM

↓

Find the differences

↓

Update only the changed elements.

This process is extremely fast.

Reconciliation

The complete process of comparing Virtual DOMs and updating the real DOM is called Reconciliation.

React automatically performs reconciliation whenever state or props change.

Developers don't need to manually update the DOM.

Why Is React Fast?

React is efficient because it:

Reduces unnecessary DOM updates.
Updates only changed elements.
Keeps the UI synchronized with data.
Improves the user experience.

It's important to remember that React is not always faster than every approach. Its main advantage is reducing unnecessary work and making UI updates predictable.

Real-World Analogy

Imagine a teacher checking a 500-page book.

Option 1:
Read every page again.

Option 2:
Read only the pages that changed.

Which is faster?

The second option.

That's exactly how the Virtual DOM works.

Example

function Counter() {
const [count, setCount] = React.useState(0);

return (
<>

{count}

  <button onClick={() => setCount(count + 1)}>
    Increment
  </button>
</>

);
}

When the button is clicked, React updates only the "

" value instead of rebuilding the entire page.

Common Misconceptions

❌ Virtual DOM is the real webpage.

✔️ No. It is only a JavaScript representation.

❌ React reloads the entire page.

✔️ No. React updates only the necessary elements.

❌ Virtual DOM makes everything instantly fast.

✔️ Performance also depends on component design, rendering strategy, and application structure.

Interview Questions

Q1. What is the Virtual DOM?

A lightweight JavaScript representation of the real DOM that React uses to determine efficient UI updates.

Q2. What is Diffing?

The process of comparing the previous and new Virtual DOM trees to identify changes.

Q3. What is Reconciliation?

React's process of applying the detected changes to the real DOM efficiently.

Q4. Why is manipulating the real DOM expensive?

Because browser rendering and layout calculations take more resources than working with lightweight JavaScript objects.

Key Takeaways

DOM stands for Document Object Model.
React uses a Virtual DOM instead of directly updating the real DOM.
React compares the old and new Virtual DOM using Diffing.
Reconciliation updates only the necessary parts of the real DOM.
This approach improves performance and provides a smoother user experience.

Final Thoughts

Understanding the Virtual DOM is one of the first major steps toward understanding how React works internally.

Instead of memorizing that "React is fast," try to understand why React is efficient. Once you grasp concepts like the Virtual DOM, Diffing, and Reconciliation, many other React features become much easier to learn.

Happy coding!