DEV Community: dbc2201

Computers Aren't Calculators — They're Spellbooks

dbc2201 — Wed, 11 Feb 2026 21:54:45 +0000

We've been thinking about computers wrong. They're not number crunchers or entertainment boxes. They're the most powerful documentation tools ever built — and programmers are the wizards who write spells precise enough to reshape reality.

Computers Aren't Calculators — They're Spellbooks

Ask someone what a computer is and you'll hear the same answers: a calculator, an entertainment system, a communication device. And sure, computers do all of those things. But defining a computer by what it does misses the point of what it is.

Here's a better framing: a computer is the most powerful documentation tool humans have invented since the book.

That might sound reductive. But sit with it for a moment, and something clicks.

Everything Is a Document

Think about what you actually do with a computer every day. You write emails. You edit spreadsheets. You update wikis, draft proposals, push code, file tickets. Even the act of "browsing the web" is really just reading documents that other people wrote and published.

The internet itself is, at its core, a system for sharing documents. HTML was literally invented so physicists could share research papers more easily. Tim Berners-Lee didn't set out to build a platform for cat videos — he wanted better documentation.

But here's where it gets interesting. Unlike the documents of the past — clay tablets, scrolls, printed books — the documents we create on computers aren't static. They can be executed.

And that changes everything.

The Document That Becomes Real

Consider a Dockerfile.

If you've never seen one, it reads like a recipe. It says: start with this operating system, install these dependencies, copy these files, run this command. It's plain text. You could print it out and hand it to someone, and they'd understand what it describes.

But here's the magic — when you give that plain text document to a machine, it doesn't just describe an environment. It creates one. Hand that same file to a colleague on the other side of the world, and their computer will build the exact same environment as yours. Byte for byte. Dependency for dependency.

The document became the thing it described. The map became the territory.

And this pattern is everywhere in software.

Source code is a document that happens to be executable. An API specification is a contract between systems, written in a shared language. Infrastructure-as-code is, quite literally, "we wrote down what our servers should look like, and the computers made it real." A .gitignore file — just a few lines of text — reshapes how an entire project behaves.

Even a simple configuration file is a document that, once read by the right program, alters the behavior of a machine. We're writing descriptions of reality and handing them to computers that make those descriptions true.

If that isn't magic, I don't know what is.

So What Does That Make Programmers?

If computers are spellbooks, then programmers are the wizards of the modern age. And the metaphor holds up better than you'd expect.

The Languages Are Arcane. Wizards study ancient tongues that most people can't read. Programmers study Python, Rust, Haskell, and SQL — languages that look like gibberish to the uninitiated but carry enormous power when wielded correctly. And just like a misplaced syllable in a spell, a missing semicolon can make everything explode.

The Tools Are Sacred. Every wizard has their wand, their staff, their enchanted artifacts. Programmers have their IDEs — and they're fiercely loyal to them. Vim purists will fight VS Code converts with the same energy as rival magical orders. Customizing your IDE with themes, keybindings, and extensions? That's just enchanting your gear for maximum power.

The Elixirs Are Real. Every wizard needs potions. Programmers run on caffeine during the day and something stronger after a production incident at 2 AM. The coffee isn't a preference — it's a dependency. (Pun very much intended.)

The Career Path Is an Apprenticeship. Junior developers are apprentices, copying spells from Stack Overflow without fully understanding the incantations. Mid-level developers are journeyman mages who can adapt known spells to new situations. Senior developers are the grey-bearded wizards who've seen things break in ways that shouldn't be physically possible — and somehow fixed them with three lines of code and a prayer.

And the software architect? That's the wizard in the tower, drawing diagrams on enchanted whiteboards that nobody else can fully interpret but somehow keep the entire kingdom running.

The Deeper Truth

Here's what makes this more than just a fun metaphor.

When we write software, we're not just "telling computers what to do." We're authoring documents so precise that machines can interpret them and reshape the digital world accordingly. And increasingly, that digital world is the world — it's how we bank, communicate, navigate, learn, and work.

Programming is, at its heart, an act of documentation. It's the practice of writing things down so carefully, so unambiguously, that reality bends to match what you wrote.

Books changed the world by letting us preserve and share knowledge across time and space. Computers took that idea and added a twist: the knowledge executes itself.

We went from "write it down so others can learn" to "write it down so the universe rearranges."

So the Next Time Someone Asks What You Do...

Don't say you "work with computers." Don't say you "write code."

Say you write spells in arcane languages, using enchanted tools, fueled by ancient elixirs — and when the incantation is correct, reality changes.

It's technically accurate. And honestly? It sounds way cooler at parties.

What's your favorite "spell" you've ever written — the piece of code that felt like actual magic when it worked? Drop it in the comments. Bonus points if it broke something spectacular first.

The Developer You Could Become: Reclaiming India's Place in Open Source

dbc2201 — Sat, 17 Jan 2026 12:13:13 +0000

A roadmap for building genuine contributors—from someone who's walked the same path

Before We Begin: I Need to Tell You Something

In 2018, I was exactly where you might be right now.

I was chasing credentials. Hunting for that one thing that would make my resume stand out. And then I cracked the Google India Challenge Scholarship—selected through Udacity, backed by Google Inc.

That moment changed my trajectory. But here's what I didn't understand back then: the scholarship didn't make me a better developer. The learning that came after did.

I'm telling you this because I need you to trust me when I say: I understand the pressure you're under. The placement anxiety. The family expectations. The feeling that everyone around you has figured out some secret you haven't.

I've been there. I've felt that desperate need to have something on my resume that proves I belong.

But I've also seen what happens when that desperation leads people down the wrong path. And I've spent years training thousands of engineers, watching some flourish and others struggle—not because of talent, but because of the choices they made early on.

So let me share what I wish someone had told me.

The Developer They Remember

Somewhere in Bangalore, a maintainer of a popular web framework is scrolling through pull requests on a Saturday morning. Coffee in hand, bleary-eyed, volunteering their weekend because they love the project they've built over seven years.

They pause at a PR titled "Update README."

It adds one line: their name. Just... their name. Added to the heading of the README file.

They sigh. Close. Mark as spam. Lock thread. Report user.

This ritual will repeat eleven more times before lunch. Each notification pings 485 watchers. Each one costs five minutes of attention. Each one makes them wonder why they bother.

Now imagine a different PR. Same maintainer, same Saturday morning. But this one fixes a bug the contributor actually encountered. The commit message explains the problem clearly. The code is tested. The contributor has been in the community for three months, helping newcomers in Discord, answering questions they once asked themselves.

The maintainer smiles. Merges. Remembers why open source still matters.

Which contributor do you want to be?

The Uncomfortable Truth: What's Actually Happening Right Now

I need to show you something that's been happening—and is still happening as you read this.

The ExpressJS Incident (It's Not Ancient History)

ExpressJS is one of the most popular Node.js frameworks in the world. Millions of applications run on it. And right now, if you go to their GitHub repository and look at closed pull requests, you'll find pages upon pages of PRs titled "Update README" or "Update README.md."

What are these PRs doing?

Adding names. Just names. "Swapnil." "Adarsh." "Speedy Navigation." Contributors simply adding their own names to the H1 heading of the README file.

As one developer who investigated this pointed out, searching "Update README" on that repository shows 20 pages of mostly garbage PRs mixed with a few legitimate ones. Another analysis found that approximately 22.8% of all open PRs on ExpressJS are these spammy README updates.

This isn't a bot attack. These are real people—our fellow Indian developers—following tutorials without thinking.

The Source: A Tutorial Watched by Millions

Here's what happened, and I'm sharing this not to shame anyone, but because you need to understand the mechanics of how this works.

A popular Indian educational YouTube channel with over 7 million subscribers published a Git and GitHub tutorial. It's been watched over 5.6 million times. And 99% of the video is genuinely helpful.

But there's a 3-minute segment near the end where the instructor demonstrates how to fork a repository. She uses the official ExpressJS repository for the demonstration. She shows how to edit the README (adding a name), and how to create a pull request.

Now, here's the thing: she explicitly warns viewers not to actually submit this PR. She says, verbatim: "This is a useless commit... do not actually create this pull request."

But here's what happens with a video that has 5.6 million views:

Audience retention graphs show viewers often stop listening carefully by the end of tutorials
Many viewers watch with the sound low, just following the visual steps
Even if only 1% ignore the verbal warning and follow the visual steps...

That's 56,000 potential spam PRs.

As one Indian developer doing the math put it: with 1.3 million views at the time he checked, even 1% means 13,000 spam PRs for maintainers to deal with.

Why This Keeps Happening (Year After Year)

What makes this particularly painful is that this issue was identified over two years ago. Multiple prominent developers made videos about it. Comments on the original tutorial warn viewers not to create test PRs on official repos.

YouTube Studio allows creators to trim segments out of existing videos without re-uploading. The problematic 3-minute section could have been removed with a few clicks.

It wasn't.

And so every year—especially during Hacktoberfest season, or when new college terms begin—the spam comes in waves. ThePrimeagen, a popular developer and content creator, documented that two years later, it's still happening. The spam has spread beyond ExpressJS to other repositories, including Node.js itself.

The Real Consequences (They're Worse Than You Think)

Here's what many students don't realize:

1. You can get your entire GitHub account banned.

GitHub's Terms of Service explicitly prohibit "opening empty or meaningless issues or pull requests." As Hitesh Choudhary (Chai aur Code) explained in a video about this issue, getting flagged as a spammer doesn't just lock you out temporarily—it can destroy your reputation as a developer.

One user's account got suspended, locking them out of all their repositories—including sensitive ones—with no way to back them up. They eventually got it unlocked after contacting support, but the warning is clear.

2. CI/CD costs real money.

When you open a PR, it often triggers automated tests (Continuous Integration) on the maintainer's servers. Thousands of garbage PRs mean wasted computational power and money on changes that add zero value.

3. It reinforces the worst stereotypes.

Because of India's large population, even a small percentage of bad actors creates a massive volume of spam. This reinforces negative stereotypes about Indian developers in the global community—stereotypes that affect all of us, including those doing excellent work.

It's Not You—It's a System That Shaped You

Now, before you think I'm here to lecture you, let me say something important:

If you've ever felt the urge to just "get something on GitHub," you're not broken. You're responding rationally to a broken system.

Consider the math. Major coding programs offer stipends of ₹1.2-2.5 lakh over a few months. The average engineering internship pays around ₹17,778/month. Even elite internships cap around ₹50,000-80,000/month.

Colleges celebrate program selections as institutional achievements. Your seniors tell you that a "green contribution graph" matters for placements. YouTube thumbnails scream about earning lakhs from stipends.

The economic logic is overwhelming. The social pressure is real.

And here's the deeper problem: multiple studies have documented that our engineering education system "still leans heavily on classroom lectures, textbooks, and rote learning." Open source isn't in most curricula. Git workflows, community etiquette, how to read unfamiliar codebases—these skills are left for you to figure out on your own.

So when a YouTube video shows a shortcut, is it any surprise thousands take it?

But here's what I want you to understand: the shortcuts don't lead where you think they lead.

Chasing green contribution squares or free t-shirts via spam PRs has—and I cannot stress this enough—0% impact on your actual career growth. The hiring managers I talk to don't count contribution squares. They look at the actual code. They check if your PRs were merged or closed as spam. They notice if your "contributions" are just README edits.

The irony is brutal: the very thing you're doing to improve your resume could be what destroys it.

A Moment of Encouragement (Yes, Really)

Here's something that might actually make you feel better.

One developer who analyzed this situation offered a surprisingly motivating perspective to skilled developers worried about market saturation:

"Your competition consists of these people who blindly copy-paste without thinking. If you have genuine skills and critical thinking, you have nothing to worry about—because the vast majority of the crowd lacks these basics."

Read that again.

The bar is not as high as you think. You don't need to be a genius. You don't need to attend an IIT. You don't need to have been coding since age 10.

You just need to be someone who thinks before they act. Someone who reads the instructions. Someone who asks, "Does this actually add value?"

That alone puts you ahead of a terrifying percentage of your peers.

What Actually Works: Lessons From Those Who Got It Right

Let me tell you about programs that successfully build real contributors.

Outreachy's Three-Phase Model

Outreachy places contributors into open source projects. Here's how selection works:

Phase 1: You write essays explaining your genuine interest. They explicitly warn against AI-generated content. They're looking for authentic motivation.

Phase 2: You spend four weeks actually contributing. Not writing proposals about what you might do someday—doing the work, now, in public. This is the brutal but beautiful filter: it selects for people who can work independently, communicate publicly, and prioritize quality over quantity.

Phase 3: Mentors rank applicants 1-5 based on demonstrated work. "5 = Amazing applicant, could become maintainer, extensive high-quality contributions."

The key insight: selection happens after demonstrated contribution, not before. You can't game a system that requires you to actually do the thing.

The Apache Way

The Apache Software Foundation uses a similar philosophy. Contributors progress through levels: User → Contributor → Committer → Project Management Committee Member → Foundation Member.

Their core principle is "Community Over Code"—they'd rather have a healthy community with mediocre code than brilliant code maintained by toxic people. Because over time, healthy communities produce better code anyway.

Post-Crisis Hacktoberfest

After the 2020 spam crisis (which I'm sure you've heard about—it was covered by The Register, InfoQ, and sparked the #shitoberfest hashtag), the annual open-source celebration made structural changes:

Maintainers must opt-in by adding a specific tag
Contributions only count when maintainers explicitly label them "accepted"
Users with multiple spam PRs are permanently banned
An advisory council provides ongoing feedback

By 2022, the same program saw 146,891 participants from 194 countries producing 335,000 contributions—with measurably higher quality.

The lesson: give gatekeepers control, require demonstrated work before recognition, and make gaming harder than genuine contribution.

Understanding What You're Walking Into

Before you submit your first pull request, I need you to understand something that will change how you approach every interaction.

According to the 2024 Tidelift Maintainer Report:

60% of maintainers are not paid for their work. At all.
60% have quit or considered quitting maintaining their projects.
44% cite burnout as the reason.

These are volunteers. They have day jobs, families, health problems, grief. They maintain code that powers companies worth billions—for free, on weekends, often alone.

As one developer put it bluntly: "Open Source is not a playground for absolute beginners to test buttons."

That sounds harsh. But think about it this way: would you walk into a stranger's workshop and start randomly pressing buttons on their equipment? Would you "test" hacking on Google's servers just to learn how penetration testing works?

The same principle applies here.

When you ping a maintainer asking to be assigned an issue you haven't researched... When you submit a PR that doesn't follow the contribution guidelines you didn't read... When you ask questions the documentation already answers...

You're not just wasting time. You're contributing to the burnout that's killing the ecosystem that benefits all of us.

But flip it around:

When you show up having done your homework... When your PR is small, focused, well-tested, and solves a real problem... When you help newcomers instead of just asking for help...

You become the kind of person maintainers want to mentor. The kind who might, someday, become a maintainer yourself.

A Personal Roadmap: Four Phases to Becoming a Real Contributor

Let me give you the framework I wish I'd had when I started.

Phase 1: Foundation (Before You Touch Any Codebase)

Technical skills to build:

Git proficiency: branching, rebasing, resolving conflicts, writing meaningful commit messages
Ability to set up development environments from documentation alone
Comfort reading code you didn't write

Mindset shifts to make:

"Read the manual before asking" becomes your default
You accept that maintainers don't owe you anything
You commit to contributing only to projects you actually use or care about

Practice first: Create your own repositories. Test features there. Break things in your own sandbox—not in someone else's production codebase.

Checkpoint: You can clone a project, set it up locally, run the tests, and navigate the codebase without asking anyone for help.

Phase 2: Community Orientation (Observe Before You Participate)

Activities:

Join the project's communication channels (Discord, Slack, mailing lists)
Read the last 50 issues and 20 merged PRs
Identify who the maintainers are and how they communicate
Understand the project's rhythms: when are people active? How long do reviews take?

The silent observation period matters. You're not just learning the codebase—you're learning the culture. Every community has unwritten rules. The only way to learn them is to watch.

Checkpoint: You can explain the project's governance structure, name the active maintainers, and describe what a good contribution looks like for this specific project.

Phase 3: Quality Contribution (Your First Real Work)

Good first contributions:

Fix a bug you actually encountered while using the project
Improve documentation that genuinely confused you
Write tests for untested code paths
Respond to issues with helpful debugging context

Quality standards:

PRs are small (50-200 lines ideally)
Commit messages follow the project's conventions (check their CONTRIBUTING.md)
You respond to review feedback completely and promptly
The key test: You don't need the certificate to feel good about the work

As ThePrimeagen advised: Join the Discord of a project you like. Ask for advice on which issue to tackle. Spend hours debugging, adding print statements, understanding the code. Submit a PR with actual value.

"Real joy in programming comes from solving actual problems, not from adding your name to a README."

Checkpoint: You have at least one contribution merged with positive feedback from a maintainer.

Phase 4: Sustained Participation (Where Real Growth Happens)

Activities:

Move beyond "good first issues" to meatier challenges
Help review other people's PRs (even without commit access)
Answer questions from newer contributors
Take on documentation ownership or triage duties

6-month metrics that matter:

Are you still contributing to the same project?
Do maintainers recognize your name?
Have you helped anyone else get started?

Checkpoint: Someone refers to you as a regular contributor, not a drive-by participant.

Start Today: Your First Three Actions

Don't wait until you "know enough." Here's what you can do this week:

1. Pick ONE tool you use daily that's open source

Maybe it's VS Code, a testing library, or a linter. Don't pick something famous just because it's famous. Pick something you actually use—because you'll understand the problems it has.

2. Find and join their community

Look for a Discord, Slack, or discussion forum. Introduce yourself briefly. Then lurk. Read. Learn how people talk to each other there.

3. Set up the project locally

Clone it. Read the README. Follow the setup instructions. Run the tests. If something in the docs confused you, write it down—that confusion is your first potential contribution.

That's it. No PRs yet. No issues opened. Just presence, observation, and preparation.

A Word About Your "Competition"

I want to leave you with something that might fundamentally change how you see your situation.

You're worried about saturation. About competition. About whether there's room for you in tech.

But think about who your "competition" actually is:

People who submit PRs adding their name to README files
People who follow tutorials one-to-one without thinking
People who can't understand the purpose of a Pull Request
People who chase green squares instead of actual skills

As one developer observed: if you have genuine skills and critical thinking, you have nothing to worry about—because the vast majority of the "crowd" lacks these basics.

The bar is not adding your name to ExpressJS. The bar is solving real problems.

And that bar? It's completely achievable. Not because you need to be exceptional—but because so many people aren't even trying to clear it.

Resources for the Journey

Learning Git properly:

Oh My Git! (interactive game): https://ohmygit.org/
Git Katas (exercises): https://github.com/eficode-academy/git-katas

Understanding open source culture:

The Apache Way: https://www.apache.org/theapacheway/
First Contributions: https://firstcontributions.github.io/

Finding projects that welcome newcomers:

Good First Issues: https://goodfirstissue.dev/
CodeTriage: https://www.codetriage.com/

Indian open source communities:

FOSS United: https://fossunited.org/
amFOSS (Amrita): https://amfoss.in/

A Final Word

I started this by telling you about my Google India Challenge Scholarship in 2018. Let me tell you what I didn't say:

That credential opened doors. But what kept those doors open was the work I did after—the skills I built, the communities I joined, the problems I solved. The credential was a starting point, not a destination.

If I had gotten that scholarship by gaming the system, by cheating, by submitting spam... it would have been worthless. Because the moment I was asked to actually do something, I would have been exposed.

The path I've described in this post is harder. It takes longer. It requires you to care about more than credentials.

But at the end of it, you'll be someone who can actually build things. Someone maintainers trust. Someone who gets opportunities not because of resume keywords, but because people have seen your work.

Someone who, when they say "I'm an open source contributor," actually is.

The developer you could become is waiting. Start today.

If this resonated with you, share it with a friend who needs to hear it. And if you're already doing the hard work of genuine contribution—thank you. The community needs more people like you.

— Divyansh Bhardwaj
Corporate & Technical Trainer | Google India Challenge Scholarship Recipient 2018
Teaching engineers to think, not just code

The Java Developer's Roadmap for 2026: From First Program to Production-Ready Professional

dbc2201 — Fri, 09 Jan 2026 11:23:22 +0000

A comprehensive, modern guide to becoming a confident Java developer — built from 10+ years of training thousands of students across India and beyond.

TL;DR: The 7 Phases at a Glance

Phase	Focus	Key Outcome
0	Tools & Environment	Java 25, IntelliJ, Git ready
1	Computational Thinking	Logic before language
2	Methods & Functions	Decompose problems
3A	Core OOP	Classes, inheritance, interfaces
3B	Advanced OOP	Exceptions, threads, generics
4	Modern Java	Collections, streams, records, virtual threads
5	Data & Persistence	SQL, JDBC, JPA
6	Spring Boot 4	REST APIs, AI integration
7	Professional Practices	Testing, Docker, CI/CD

Time investment: 6-12 months of consistent practice. No shortcuts.

This Post is For You If...

You want to learn Java — properly. Not the "watch a 4-hour crash course and call yourself a developer" kind of learning. The real kind. The kind where you actually understand what you're writing, why you're writing it, and how to build software that solves real problems.

It doesn't matter who you are:

A first-year engineering student staring at your first programming course
A final-year student panicking about placements
A working professional from a non-tech background looking to switch careers
A self-taught learner who's been "learning Java" for months but still feels lost
Someone who already "knows" Java from college but can't build anything real with it

Java doesn't care about your background. Neither does this roadmap.

What matters is your willingness to put in the work. There are no shortcuts.

The Project: JanSahayak (जनसहायक — Citizen's Assistant)

Before we dive into the phases, let me tell you what you'll build. Because learning without purpose is just academic exercise.

I refuse to make you build a todo app. It's the most overused, uninspiring project in programming education. Nobody wants to look at it. Nobody is impressed by it.

Instead, you'll build JanSahayak — an AI-powered platform that helps citizens navigate government schemes, understand required documents, and access local services. This project evolves through all phases of the roadmap:

Phase	Implementation
Phase 1	CLI tool: "What documents do I need for X?"
Phase 2	Refactored with methods, file I/O for data storage
Phase 3	OOP design: Citizen, Document, Scheme, Service classes
Phase 4	Modern Java: Records for DTOs, Streams for processing
Phase 5	Database integration with PostgreSQL
Phase 6	REST API with Spring Boot 4, AI-powered with Spring AI
Phase 7	Dockerized, tested, deployed with CI/CD

Choose Your Own Adventure

Don't like JanSahayak? Choose a different domain with the same architecture:

KisanMitra (किसानमित्र) — Agricultural advisory platform
SwasthyaSathi (स्वास्थ्यसाथी) — Health information assistant
VidyaSahay (विद्यासहाय) — Educational resource navigator
RojgarDoot (रोज़गारदूत) — Job/skill matching platform

Or pick a problem from the Smart India Hackathon — real problems that real organizations need solved. Check out the problem statements for inspiration.

The architecture blueprint remains the same. The domain is your choice.

The Question I've Been Asked 10,000 Times

"Sir, how do I get started with Java?"

I've been teaching and training developers since 2014 (officially since 2018), and this question has never stopped coming. Not once. Every batch, every bootcamp, every institution — the same question, the same anxiety in the eyes.

And here's the thing: it's a good question. Perhaps the most important question a beginner can ask. Because how you start determines everything that follows.

Back in 2021, I wrote a roadmap that went viral in the Java community. Every major Java Twitter account shared it. Students from across the world reached out saying it helped them find direction.

But 2021 was a different world. The job market was different. The technology was different. Java itself is different now.

So here we are — a refreshed, battle-tested roadmap for 2026 and beyond.

2021 vs 2026: How the Industry Has Changed

Five years might not seem like much, but in technology, it's an eternity. Here's what's changed since my original roadmap:

What a Java Developer Needed in 2021

Area	2021 Requirements
Java Version	Java 11 or 16, with Java 8 still common
Learning Approach	Start with `public static void main`, explain ceremony later
Spring Version	Spring Boot 2.x
AI Integration	Not expected
Concurrency	Traditional threads, ExecutorService
Testing	Nice to have, often learned "later"
DevOps	Optional for beginners
Problem Solving	Focus on competitive programming sites

What a Java Developer Needs in 2026

Area	2026 Requirements
Java Version	Java 25 LTS (released September 16, 2025) with modern features as defaults
Learning Approach	Computation-first with simplified syntax
Spring Version	Spring Boot 4 (released November 20, 2025) with Spring Framework 7
AI Integration	Spring AI is table stakes
Concurrency	Virtual Threads (stable), Structured Concurrency (preview)
Testing	Non-negotiable from day one; JUnit 6 is the new default
DevOps	Docker, CI/CD expected for entry-level
Problem Solving	Real-world projects with hackathon-style challenges

The Skill Gap Reality

In 2021, knowing Core Java well could get you interviews. In 2026, that's just the starting line.

New mandatory skills:

AI Integration: Companies expect you to use AI tools effectively AND build AI-powered features
Modern Java Features: Records, pattern matching, sealed classes aren't "advanced" — they're baseline
Virtual Threads: The old thread-pool-for-everything approach is outdated
API Design: REST isn't enough; you need API versioning, GraphQL awareness
Observability: OpenTelemetry, metrics, and tracing from day one

Skills that evolved:

Spring: From Boot 2.x to Boot 4.0 — completely different paradigm with modular codebase, null safety, and HTTP Service Clients
Testing: From "write tests when you have time" to TDD being expected; JUnit 6 is now the default in Spring Boot 4
Version Control: From basic Git to full PR workflows with conventional commits

The uncomfortable truth: The 2021 roadmap's four stages (Syntax → OOP → Collections → Problem Solving) produced developers who could pass coding tests. The 2026 reality demands developers who can build, deploy, and maintain production software.

Why Continuous Learning is Non-Negotiable

Look at this progression:

2021: Java 16, Spring Boot 2.4, traditional threads
2022: Java 17 LTS, Spring Boot 2.7, virtual threads preview
2023: Java 21 LTS, Spring Boot 3.0, pattern matching stable
2024: Java 23, Spring Boot 3.3, structured concurrency preview
2025: Java 25 LTS, Spring Boot 4.0, AI integration standard
2026: You are here. What's next?

The developers who thrived through these changes weren't necessarily the smartest — they were the ones who never stopped learning. They stayed curious. They didn't just learn Java once; they evolved with it.

This industry will leave you behind if you stand still. That's not meant to scare you — it's meant to prepare you. The good news? Java has been evolving beautifully, and each evolution has made developer lives easier, not harder.

Before We Begin: Some Hard Truths

Truth #1: Learning a Programming Language is Like Learning a Spoken Language

Your brain needs to rewire itself. You need to think differently. You'll be frustrated, confused, and occasionally wonder if you're smart enough for this.

You are. Everyone goes through this. The difference between those who succeed and those who give up isn't intelligence — it's persistence. The willingness to sit with confusion until clarity arrives. The discipline to practice even when it's boring.

Truth #2: There is No "Advanced" Java

Let me say something that might surprise you: the distinction between "Core Java" and "Advanced Java" is largely a market gimmick.

Yes, it made sense in the 1990s when object-oriented programming was a paradigm shift. But today? Every modern language has adopted these concepts. The "advanced" features (lambdas, streams, records, pattern matching) aren't advanced — they're just Java. They're better defaults that the language now promotes.

When someone asks me if they should "first complete Core Java before moving to Advanced Java," I tell them they're asking the wrong question. You should learn Java — all of it — progressively, as you need it. The language is one continuous journey, not two separate destinations.

Truth #3: What Programming Languages Actually Do

Here's something many beginners miss: every programming language does the same fundamental thing — it tells a computer what to do.

In the end, everything becomes 1s and 0s for your CPU. It doesn't matter what language you use to write your next application. Languages exist for the efficiency and benefit of developers, not computers.

Java gives you a particular set of tools and patterns that work exceptionally well for building large-scale, maintainable, enterprise-grade software. That's why it's been among the world's most popular languages for three decades.

Truth #4: AI Will Not Replace You (But It Will Change How You Work)

I see the anxiety in my students' eyes when they ask: "Sir, will AI replace programmers?"

No. And here's why.

AI is a tool, governed by rules, just like any other tool. A hammer doesn't replace a carpenter. A calculator doesn't replace a mathematician. AI doesn't replace programmers — it amplifies them.

But here's the catch: a tool is only as good as the person wielding it.

If you don't understand what code does, you can't verify if AI-generated code is correct. You can't debug it. You can't improve it. You can't explain it in an interview. You become a "vibe coder" — someone who prompts AI until something works, without understanding why it works.

The developers who will thrive are those who use AI to accelerate their work while maintaining deep understanding. Who use AI to learn faster, not to avoid learning altogether.

That's what this roadmap will teach you to do.

The 2026 Transformation: Java's New On-Ramp

Something remarkable happened with Java 25 LTS (released September 16, 2025). The language designers finally addressed a problem that educators have complained about for 25 years: the ceremony required to write your first program.

Brian Goetz (Java's Language Architect at Oracle) and the team designed what they call a "smooth on-ramp" to Java programming.

The classic "Hello World" in Java used to look like this:

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

Five lines packed with concepts a beginner can't possibly understand on day one:

public (twice!) — access modifiers
class — object-oriented programming
static — a concept that creates bad habits that must be unlearned
void — return types
String[] args — arrays and command-line arguments
System.out.println — three different concepts chained together

Now, in Java 25, your first program looks like this:

void main() {
    println("Hello World");
}

That's it. No ceremony. No magic incantations. Just logic.

And here's the beautiful part: when you're ready to learn about classes, access modifiers, and the static keyword, you simply add them to what you already know. Nothing needs to be unlearned.

The Roadmap: A Computation-First Approach

Based on years of teaching experience and the latest pedagogical research, I recommend what I call a Computation-First approach. Here's the philosophy:

Phase	Focus	Why
Phase 0	Environment & Tools	You can't learn to drive without a car
Phase 1	Computational Thinking	Focus on logic, not language ceremony
Phase 2	Functions & Methods	Decompose problems into reusable blocks
Phase 3A	Core Object-Oriented Thinking	Model the real world with classes and objects
Phase 3B	Advanced OOP Patterns	Exceptions, threads, generics
Phase 4	Modern Java	Collections, streams, records, virtual threads
Phase 5	Data & Persistence	Databases, JDBC, JPA
Phase 6	Spring Boot 4 & APIs	Build real backend applications with AI integration
Phase 7	Professional Practices	Testing, Docker, CI/CD, Git workflows

Let me walk you through each phase.

Phase 0: Your Toolkit

Before you write a single line of code, you need your tools ready.

Required:

Java 25 LTS — Download from the official OpenJDK site or use SDKMAN
IntelliJ IDEA — The 2025.3 release unified Community and Ultimate editions into a single product; core features remain free for both commercial and non-commercial use
Git — Version control is non-negotiable in 2026
GitHub Account — Your code needs a home
A Reference Book — I recommend "Java: A Beginner's Guide" by Herbert Schildt (9th Edition)

Why IntelliJ?

I know VS Code is popular. If you're on a limited machine and VS Code is your only option, that's fine — I'll sprinkle in guidance for you throughout the reference document.

But IntelliJ is purpose-built for Java. Its code completion, refactoring tools, and debugger will teach you as you code. With the unified 2025.3 release, you get a single installer with core Java development features free out of the box, plus a 30-day trial of advanced features.

Why Git from Day 1?

Because every piece of code you write should be version-controlled. This isn't optional. This isn't "something you'll learn later." From your very first program, you'll be committing, pushing, and building a history of your learning journey.

Phase 1: Computational Foundations

Goal: Think like a programmer. Express logic in code.

Using Java 25's simplified syntax, you'll learn to solve problems before worrying about language ceremony. This phase is about training your brain to break down problems into steps a computer can execute.

1.1 Syntax and Semantics

Data Types (The 8 Java Primitive Types: byte, short, int, long, float, double, char, boolean)
Variables (declaration, initialization, the var keyword)
Type Conversion & Casting (widening, narrowing, explicit casting)
Automatic Type Promotion in Expressions
Arrays (single-dimensional, multi-dimensional, length property)
Operators in Java: Arithmetic, Bitwise, Relational, Boolean, Assignment, Ternary, and Operator Precedence
Control Statements: if, if-else, if-else-if ladder, switch statement (traditional and modern switch expressions)
Iteration Statements: while, do-while, for, enhanced for-each, nested loops, break, continue, and labeled statements
Using Command-Line Arguments
The String class (creation, immutability, common methods)
Varargs (Variable Length Arguments)
Scanner class for input
BufferedReader class for efficient input

The key insight: At this phase, you're not learning "Java." You're learning to think computationally. The syntax is just how you express those thoughts.

Practice: CodingBat — Start with Warmup-1, String-1, Array-1. Don't move forward until you can solve these without looking up syntax.

Phase Complete Checkpoint

Before moving to Phase 2, you should be able to:

Write a program that reads input and produces output based on conditions
Use loops to process collections of data
Explain why int x = 10/3 gives you 3, not 3.333
Debug a simple program by reading error messages

Phase 2: Functions & Methods

Goal: Break problems into smaller, reusable pieces.

Methods are the building blocks of all software. Before you learn about objects, you need to master the art of decomposing problems into functions that do one thing well.

2.1 Methods

Declaring and Using Methods (method signature, method body)
Method Return Types (void and value-returning methods)
Method Parameters and Arguments
Pass by Value semantics in Java
Method Overloading (same name, different parameters)
Recursion (base case, recursive case, call stack, tail recursion, head recursion)
Variable Scope (local variables, block scope, shadowing)
The Call Stack and Stack Frames

Why this before OOP?

Because understanding methods is foundational. A class is just a container for related methods and data. If you don't understand methods, classes will feel like magic.

Practice: Complete CodingBat Logic-1, Logic-2, String-2. Then move to Exercism Java Track for more substantial exercises.

Phase Complete Checkpoint

Before moving to Phase 3A, you should be able to:

Extract repeated code into a method
Write a recursive function to solve a simple problem (like factorial or Fibonacci)
Explain what the call stack is and why it matters
Overload a method with different parameter types

Phase 3A: Core Object-Oriented Programming

Goal: Learn to model the real world using classes and objects.

You've been writing programs as sequences of instructions. Now comes the paradigm shift: instead of doing things, you'll define things that do. A Citizen isn't a list of variables—it's an entity with identity, state, and behavior.

This phase builds the mental model that powers enterprise Java. Take your time here.

3.1 Classes and Objects

Every Java program you've written has secretly been using classes. Now you'll create your own.

Types of Program Units in Java (Class, Abstract Class, Interface, Enum, Record)
Declaring Classes
Creating Objects (the new keyword, object references)
Reference Types vs Primitive Types
Instance Variables (Fields)
Methods (instance methods, method signatures)
Constructors (default constructor, parameterized constructors)
The this keyword
Overloading Constructors
Using Objects as Method Parameters and Return Types
The static keyword (static fields, static methods, static blocks)
The final keyword (final classes, final methods, final variables/constants)
Nested Classes and Inner Classes

3.2 Inheritance

Inheritance lets you build on existing code without rewriting it. It's one of the most powerful tools for code reuse—but also one of the most misused.

Inheritance in Java (extends keyword)
Superclass and Subclass relationships
The super keyword
Types of Inheritance Hierarchies (single, multilevel)
Method Overriding and the @Override annotation
Polymorphism (runtime polymorphism, dynamic method dispatch)

3.3 Abstract Classes and Interfaces

These define contracts that classes must fulfill. They're the foundation of flexible, maintainable architecture.

Abstract Classes (abstract methods, concrete methods)
Interfaces (defining, implementing, multiple inheritance of type)
Default Methods in Interfaces
Static Methods in Interfaces
Private Methods in Interfaces (Java 9+)
Functional Interfaces (single abstract method)

3.4 Packages and Access Control

Encapsulation is about hiding complexity. Packages and access modifiers are your tools for building clean, maintainable systems.

Packages (creating, naming conventions, CLASSPATH)
Importing Packages
Access Modifiers (public, protected, default/package-private, private)
Encapsulation and Information Hiding

Practice: Complete Exercism's "Classes" and "Inheritance" exercises in the Java track.

Phase Complete Checkpoint

Before moving to Phase 3B, you should be able to:

Create a class with private fields, a constructor, and getter methods
Explain why we hide data behind methods (not just "because OOP says so")
Write a simple inheritance hierarchy without looking up syntax
Implement an interface and explain when to use interface vs abstract class

Phase 3B: Advanced OOP Patterns

Goal: Master the constructs that enable large-scale, maintainable code.

Core OOP taught you to think in objects. This phase teaches you to think in systems of objects—how they communicate, what they guarantee to each other, and how they fail gracefully.

3.5 Exception Handling

When something goes wrong (and it will), you need a plan. Exception handling is how Java programs deal with errors gracefully.

Exception Types (checked vs unchecked, Error vs Exception)
The Exception Hierarchy
try-catch blocks
finally block
try-with-resources (automatic resource management)
Multiple catch blocks and multi-catch
throw and throws keywords
Creating Custom Exceptions

3.6 Multithreaded Programming Basics

Concurrency is how programs do multiple things at once. Understanding the basics prepares you for modern concurrency in Phase 4.

The Java Thread Model
The Main Thread
Creating Threads (Thread class, Runnable interface)
Thread Lifecycle and States
sleep(), join(), thread priorities
Synchronization basics

3.7 Enumerations and Annotations

Enums give you type-safe constants. Annotations let you add metadata to your code that tools can process.

Enum Types (declaration, methods, constructors)
Type Wrappers (Integer, Double, Boolean, etc.)
Autoboxing and Unboxing
Annotations (@Override, @Deprecated, @SuppressWarnings, custom annotations)

3.8 Generics

Generics let you write code that works with any type while maintaining type safety. They're essential for understanding collections and modern Java APIs.

Introduction to Generics
Generic Classes
Generic Methods
Bounded Type Parameters (extends, super)
Wildcards (?, ? extends T, ? super T)
Type Erasure
Generic Constructors

Practice: Complete Exercism's "Generics" and "Exception Handling" exercises.

Phase Complete Checkpoint

Before moving to Phase 4, you should be able to:

Handle an exception you intentionally throw
Create a generic class that works with different types
Explain the difference between checked and unchecked exceptions
Create a simple two-thread program that shares data safely

Phase 4: Modern Java

Goal: Write idiomatic, modern Java code using the language's latest features.

This phase covers the features that distinguish modern Java from "your father's Java." These aren't advanced—they're the new baseline.

4.1 Collections Framework

Collections are the containers you use every day. You must understand these before learning Streams, because streams operate on collections.

Collection Interfaces: List, Set, Queue, Deque, Map
Collection Classes: ArrayList, LinkedList, HashSet, TreeSet, HashMap, TreeMap, PriorityQueue, ArrayDeque
Iterators and ListIterator
Immutable Collections (List.of(), Set.of(), Map.of())

Why Collections before Streams?

Because you can't understand list.stream().filter(...).collect(...) if you don't understand what a List is. Streams operate on collections. Learn the containers first.

4.2 Records and Sealed Classes

Records eliminate boilerplate for data classes. Sealed classes give you control over inheritance hierarchies.

Records (compact constructors, canonical constructors, custom methods)
Sealed Classes (sealed, permits, non-sealed, final)

4.3 Pattern Matching

Pattern matching makes your code more expressive and eliminates many explicit casts.

instanceof Pattern Matching
Pattern Matching in switch
Record Patterns
Guarded Patterns (when clause)

4.4 Text Blocks and String Enhancements

Multi-line strings are finally readable in Java.

Text Blocks (multi-line strings)
String formatted() method
String indent(), stripIndent(), translateEscapes()

4.5 Lambda Expressions

Lambdas let you treat functions as values. They're the foundation of functional programming in Java.

Lambda Expression Syntax
Functional Interfaces (@FunctionalInterface)
Built-in Functional Interfaces: Predicate, Function, Consumer, Supplier, BiFunction
Method References (:: operator)

4.6 Stream API

Streams let you process collections declaratively. They're one of the most powerful features in modern Java.

Introduction to Streams
Creating Streams (stream(), of(), generate(), iterate())
Intermediate Operations (filter(), map(), flatMap(), sorted(), distinct(), limit(), skip())
Terminal Operations (forEach(), collect(), reduce(), count(), findFirst(), findAny(), anyMatch(), allMatch(), noneMatch())
Collectors (toList(), toSet(), toMap(), groupingBy(), partitioningBy())
Parallel Streams

4.7 Optional

Optional helps you handle null values safely and expressively.

The Optional class
Creating Optionals (of(), ofNullable(), empty())
Checking and Retrieving (isPresent(), isEmpty(), get(), orElse(), orElseGet(), orElseThrow())
Transforming (map(), flatMap(), filter())

4.8 Modern Concurrency (Java 21+)

Java's concurrency model has evolved dramatically. Virtual threads change everything about how we think about concurrent programming.

Virtual Threads (stable since Java 21, Project Loom)
Structured Concurrency (StructuredTaskScope) — Note: Still in preview as of Java 25 (JEP 505)
Scoped Values (finalized in Java 25, replacement for ThreadLocal)
CompletableFuture

4.9 Date-Time API

The modern Date-Time API is immutable, thread-safe, and actually makes sense.

Practice: Complete Exercism's "Streams", "Optionals", and "Date-Time" exercises.

Phase Complete Checkpoint

Before moving to Phase 5, you should be able to:

Use streams to filter, transform, and collect data
Create a record class and explain its advantages over a regular class
Use Optional to handle potentially null values
Explain when to use virtual threads vs traditional threads

Phase 5: Data & Persistence

Goal: Store and retrieve data professionally.

A Java developer who can't work with databases is unemployable in 2026. This phase is not optional.

5.1 SQL Fundamentals

DDL: CREATE, ALTER, DROP
DML: SELECT, INSERT, UPDATE, DELETE
WHERE, ORDER BY, GROUP BY, HAVING
JOIN operations (INNER, LEFT, RIGHT, FULL)
Aggregate functions (COUNT, SUM, AVG, MIN, MAX)
Subqueries and Common Table Expressions (CTEs)

5.2 JDBC

JDBC Overview
DriverManager and database connections
Connection, Statement, PreparedStatement
ResultSet processing
Transaction management
Connection Pooling with HikariCP

5.3 JPA/Hibernate

Jakarta Persistence (JPA) concepts
Entity mapping (@Entity, @Table, @Id, @GeneratedValue)
Field mapping (@Column, @Transient)
Relationships (@OneToOne, @OneToMany, @ManyToOne, @ManyToMany)
JPQL (Java Persistence Query Language)
Criteria API

5.4 Spring Data JPA

Spring Data JPA Reference
Repository pattern (JpaRepository, CrudRepository)
Query methods (method name derivation)
@Query annotation
Pagination and Sorting

Practice: Build a data access layer for your JanSahayak project using Spring Data JPA.

Phase 6: Spring Boot 4 & Beyond

Goal: Build production-grade applications with the latest Spring ecosystem.

6.1 Spring Boot 4 Fundamentals

Spring Boot 4.0 was released on November 20, 2025 and is built on Spring Framework 7. Key features include:

Modular codebase — smaller, more focused jars
Null safety with JSpecify — portfolio-wide improvements
First-class Java 25 support (while retaining Java 17 compatibility)
API Versioning support out of the box
HTTP Service Clients — annotate interfaces, get implementations

@HttpExchange(url = "https://api.example.com")
public interface UserService {
    @GetExchange("/users/{id}")
    User findById(@PathVariable Long id);

    @PostExchange("/users")
    User create(@RequestBody CreateUserRequest request);
}

6.2 Spring Boot 4 New Features

RestTestClient: New testing support for REST APIs
OpenTelemetry Starter: spring-boot-starter-opentelemetry for metrics and traces
Kotlin Serialization: First-class support with spring-boot-kotlin-serialization-starter
Redis Observability: Auto-configured MicrometerTracing for Redis operations
Virtual Thread Integration: HTTP clients auto-configured for virtual threads when enabled
Gradle 9 Support: Build with the latest Gradle

6.3 Major Dependency Upgrades in Spring Boot 4

Dependency	Version
Spring Framework	7.0
Spring Security	7.0
Spring Data	2025.1
Hibernate	7.1
Jackson	3.0
Tomcat	11.0
Jakarta Persistence	3.2
JUnit	6.x
Testcontainers	2.0

6.4 REST API Development

@RestController
Request mapping (@GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping)
@PathVariable, @RequestParam, @RequestBody
ResponseEntity for HTTP responses
API Versioning with spring.mvc.apiversion.*

6.5 Spring Security 7.0

Spring Security Reference
Authentication vs Authorization
SecurityFilterChain configuration
Password encoding with BCryptPasswordEncoder
JWT (JSON Web Tokens) basics
OAuth 2.0 integration

6.6 Spring AI (Mandatory in 2026)

AI integration is no longer optional. Spring AI makes it straightforward.

Spring AI Reference
ChatClient for LLM interaction
Prompt engineering
Structured output (entity extraction)
RAG (Retrieval-Augmented Generation) basics
Vector stores integration (Pinecone, pgvector, Milvus)

@Service
public class AIAssistantService {
    private final ChatClient chatClient;

    public AIAssistantService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String explainScheme(String schemeName) {
        return chatClient.prompt()
            .user("Explain the " + schemeName + " scheme in simple terms")
            .call()
            .content();
    }
}

Practice: Add AI-powered features to your JanSahayak project.

Phase 7: Professional Practices

Goal: Work like a professional developer.

7.1 Testing

Testing is not optional. JUnit 6 is the default in Spring Boot 4.

JUnit 6 (@Test, @BeforeEach, @AfterEach, @DisplayName)
Assertions (assertEquals, assertTrue, assertThrows, assertAll)
@ParameterizedTest and data sources
Mockito for mocking (@Mock, @InjectMocks, when(), verify())
Spring Boot Testing (@SpringBootTest, @WebMvcTest, @DataJpaTest)
RestTestClient (new in Spring Boot 4)
Test-Driven Development (TDD) methodology

7.2 Build Tools

Maven (pom.xml, lifecycle phases, plugins)
Gradle 9 (build.gradle, tasks, plugins)
Dependency management
Multi-module projects

7.3 Containerization

Docker fundamentals (images, containers, layers)
Writing Dockerfile (multi-stage builds)
Docker Compose for multi-container applications
Container registries

7.4 Observability

OpenTelemetry with spring-boot-starter-opentelemetry
Metrics with Micrometer
Distributed tracing
Log aggregation

7.5 CI/CD

GitHub Actions workflows
Automated testing in pipelines
Build and artifact generation
Deployment automation

7.6 Git Workflows

Git branching strategies
Pull request workflows
Code review best practices
Conventional Commits
.gitignore configuration

For Those Who "Already Know Java"

Maybe you've taken a Java course in college. Maybe you've watched tutorials and built small projects. Maybe you can write code that compiles and runs.

But can you:

Explain why we use encapsulation (without just saying "it's a principle of OOP")?
Write a Spring Boot 4 REST API from scratch without copying code?
Debug a NullPointerException by reading the stack trace, not by adding print statements everywhere?
Write unit tests before writing the code?
Set up a CI/CD pipeline that automatically tests and deploys your application?
Use Virtual Threads appropriately in your applications?
Integrate AI capabilities using Spring AI?
Explain what happens when you type java MyApp and press Enter?

If you hesitated on any of these, this roadmap is still for you. Use it to identify your gaps. Skip what you truly know. Double down on what you don't.

Soft Skills Matter

Technical skills get you interviews. Soft skills get you jobs.

Commit Messages: Follow Conventional Commits:

feat: add document validation endpoint
fix: handle null scheme descriptions
docs: update API documentation
refactor: extract validation logic to service

Code Reviews:

Be kind. The person wrote this code trying their best.
Be specific. "This could be better" is useless feedback.
Ask questions instead of making demands. "What was the thinking behind this approach?" beats "This is wrong."

Technical Communication:

Write README files that actually help people use your code.
Document your APIs so others don't have to guess.
When asking for help, provide context: what you tried, what you expected, what actually happened.

The Path Forward

Here's what I want you to do right now:

Set up your environment — Java 25, IntelliJ IDEA, Git, GitHub account
Create a repository — Call it java-learning-journey or whatever speaks to you
Write your first program — Use Java 25's simplified syntax
Commit it — Your journey has officially begun

Then, follow the roadmap. Phase by phase. Don't skip ahead because something looks "too basic." Don't rush because you're anxious about the job market.

The developers who struggle most aren't those who learn slowly — they're those who build on shaky foundations.

A Final Word

The job market is brutal right now. I won't pretend otherwise. The days when knowing Java basics could land you an interview are long gone.

But here's what hasn't changed: companies still need good developers.

They need people who can solve problems, write maintainable code, work in teams, and learn continuously. This roadmap won't make you a developer in 30 days. It won't guarantee you a job. Nothing can.

What it will do is give you the skills, practices, and portfolio that make you genuinely valuable — not just someone who can solve LeetCode problems, but someone who can build real software that solves real problems.

That's worth more than any shortcut.

Now go build something.

Resources

Official Java Resources:

Dev.java - Learn Java — Primary learning resource
Oracle Java Documentation
OpenJDK
Java 25 JDK Download
Brian Goetz (Java Language Architect)

Spring Framework:

Practice:

Book:

"Java: A Beginner's Guide" by Herbert Schildt (9th Edition)

Tools:

Problem Statements:

Divyansh Bhardwaj is a Corporate and Technical Trainer specializing in Java, Spring, and Full-Stack Development. He has trained thousands of developers across educational institutions in India since 2018.

Connect:

GitHub @dbc2201
LinkedIn (https://www.linkedin.com/in/divyansh-bhardwaj-0850b07b/)

Tags: #java #programming #beginners #roadmap #career #springboot #webdev

From Philosophy to Practice: Building Your First GraphQL API with Spring Boot 4

dbc2201 — Thu, 08 Jan 2026 21:49:14 +0000

This post is for you if:

You read (or skimmed) my REST vs GraphQL: Two Philosophies, Two Eras, One Endless Debate article
You nodded along to "GraphQL thinks in queries, the client knows best"
Then you thought: "Cool philosophy, but how do I actually build one?"
You're a Java/Spring developer who learns by doing, not just reading

If that's you, welcome to Part 2. Philosophy time is over. Now we build.

The Context: Where We Left Off

In the previous article, I argued that GraphQL was born from Facebook's 2011 mobile nightmare—the realization that fetching a News Feed story shouldn't require 5+ HTTP round trips. We explored the philosophical difference:

REST asks: "What resource do you want?"

GraphQL asks: "What data do you need?"

We also saw Spring Framework 7 embrace API versioning as a first-class citizen, acknowledging that the real world is messier than academic purity.

Now, let's see what "the client knows best" looks like in actual Java code.

What We're Building

A simple Book API. Nothing fancy—just enough to understand the core concepts:

Query a book by ID
Get the book's author (demonstrating nested data fetching)
See how GraphQL resolves relationships without multiple endpoints

By the end, you'll have a running GraphQL server and understand why the code is structured the way it is.

Prerequisites

Before we start, make sure you have:

Java 25 (LTS as of September 2025—or Java 21 if you're not ready to upgrade yet)
Maven 3.9.12 (the current stable release)
Your favorite IDE (IntelliJ IDEA, VS Code with Java extensions, or even vim if you're that person)

Step 1: Create the Project

Head to Spring Initializr and configure:

Setting	Value
Project	Maven
Language	Java
Spring Boot	4.0.1 (latest stable)
Group	`com.example`
Artifact	`bookstore-graphql`
Name	`bookstore-graphql`
Packaging	Jar
Java	25

Dependencies to add:

Spring Web
Spring for GraphQL

Click Generate, unzip, and open in your IDE.

Alternatively, here's the pom.xml you should end up with:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>4.0.1</version>
        <relativePath/>
    </parent>

    <groupId>com.example</groupId>
    <artifactId>bookstore-graphql</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>bookstore-graphql</name>
    <description>GraphQL API with Spring Boot 4</description>

    <properties>
        <java.version>25</java.version>
    </properties>

    <dependencies>
        <!-- Spring Web (still needed for HTTP transport) -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!-- Spring for GraphQL -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-graphql</artifactId>
        </dependency>

        <!-- Testing -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.graphql</groupId>
            <artifactId>spring-graphql-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

A note on versions: Spring Boot 4.0.1 ships with Spring for GraphQL 2.0.1, Spring Framework 7.0.2, and GraphQL Java 25.0. The versions are managed by the parent POM, so you don't need to specify them explicitly. This is one of Spring Boot's gifts to humanity.

Step 2: Define the Schema (Schema-First Development)

Here's something important: GraphQL is schema-first by design.

Unlike REST, where you might design your endpoints as you go, GraphQL forces you to think about your data contract upfront. The schema is the API documentation. The schema is the contract between client and server.

Create the file src/main/resources/graphql/schema.graphqls:

type Query {
    bookById(id: ID!): Book
    allBooks: [Book!]!
}

type Book {
    id: ID!
    title: String!
    pageCount: Int
    author: Author!
}

type Author {
    id: ID!
    firstName: String!
    lastName: String!
}

Let me break down what's happening here:

type Query — This is the entry point. Every GraphQL API has a Query type that defines what clients can ask for. Think of it as your "read operations" menu.

bookById(id: ID!): Book — A query that takes a required (!) ID and returns a Book. The ! means "non-null"—the client must provide this argument.

[Book!]! — This reads as: "a non-null array of non-null Books." Yes, you can have null arrays OR arrays with null elements in GraphQL. The ! placement matters.

Nested types — Notice how Book has an author field of type Author. This is where GraphQL shines. The client can ask for just the book title, or dive deep into author details—same endpoint, same schema, different queries.

Step 3: Create the Domain Models

Now we need Java classes that match our schema. Java records are perfect for this—immutable, concise, and they generate equals(), hashCode(), and toString() for free.

Create src/main/java/com/example/bookstoregraphql/model/Book.java:

package com.example.bookstoregraphql.model;

public record Book(
    String id,
    String title,
    Integer pageCount,
    String authorId  // Note: we store the ID, not the full Author object
) {
    // Sample data - in reality, this would come from a database
    private static final java.util.List<Book> BOOKS = java.util.List.of(
        new Book("book-1", "Harry Potter and the Philosopher's Stone", 223, "author-1"),
        new Book("book-2", "Moby Dick", 635, "author-2"),
        new Book("book-3", "Interview with the Vampire", 371, "author-3"),
        new Book("book-4", "The Great Gatsby", 180, "author-4"),
        new Book("book-5", "Clean Code", 464, "author-5")
    );

    public static Book getById(String id) {
        return BOOKS.stream()
            .filter(book -> book.id().equals(id))
            .findFirst()
            .orElse(null);
    }

    public static java.util.List<Book> getAll() {
        return BOOKS;
    }
}

Create src/main/java/com/example/bookstoregraphql/model/Author.java:

package com.example.bookstoregraphql.model;

public record Author(
    String id,
    String firstName,
    String lastName
) {
    private static final java.util.List<Author> AUTHORS = java.util.List.of(
        new Author("author-1", "Joanne", "Rowling"),
        new Author("author-2", "Herman", "Melville"),
        new Author("author-3", "Anne", "Rice"),
        new Author("author-4", "F. Scott", "Fitzgerald"),
        new Author("author-5", "Robert C.", "Martin")
    );

    public static Author getById(String id) {
        return AUTHORS.stream()
            .filter(author -> author.id().equals(id))
            .findFirst()
            .orElse(null);
    }
}

💡 Production Note: We're using static lists inside records for simplicity. In a real application, you'd inject BookRepository and AuthorRepository (Spring Data JPA, for example) and fetch data from a database. The GraphQL resolution pattern stays the same—only the data source changes.

Why authorId instead of Author in the Book record?

This is a deliberate design choice. In the GraphQL schema, Book.author is of type Author. But in our Java model, we store authorId as a String.

Why? Because GraphQL resolves fields lazily. If the client only asks for book.title, we never need to fetch the author. If they ask for book.author.firstName, then we resolve it. Storing the full Author object would force eager loading—exactly the N+1 problem we're trying to avoid.

Step 4: Create the Controller (Data Fetchers)

This is where the magic happens. Spring for GraphQL uses annotations that feel familiar if you've written REST controllers, but they work fundamentally differently.

Create src/main/java/com/example/bookstoregraphql/controller/BookController.java:

package com.example.bookstoregraphql.controller;

import com.example.bookstoregraphql.model.Author;
import com.example.bookstoregraphql.model.Book;
import org.springframework.graphql.data.method.annotation.Argument;
import org.springframework.graphql.data.method.annotation.QueryMapping;
import org.springframework.graphql.data.method.annotation.SchemaMapping;
import org.springframework.stereotype.Controller;

import java.util.List;

@Controller
public class BookController {

    // Maps to: Query.bookById(id: ID!)
    @QueryMapping
    public Book bookById(@Argument String id) {
        return Book.getById(id);
    }

    // Maps to: Query.allBooks
    @QueryMapping
    public List<Book> allBooks() {
        return Book.getAll();
    }

    // Maps to: Book.author
    // This is called ONLY when the client requests the author field
    @SchemaMapping
    public Author author(Book book) {
        return Author.getById(book.authorId());
    }
}

Let me explain these annotations because they're doing a lot of work:

@QueryMapping — Binds this method to a field in the Query type. The method name (bookById) must match the field name in your schema. Spring for GraphQL registers this as a "data fetcher" for that field.

@Argument — Extracts a named argument from the GraphQL query. The parameter name (id) must match the argument name in your schema.

@SchemaMapping — This is the interesting one. It binds to a field on a type (not Query). When a client asks for book.author, GraphQL needs to know how to resolve that. The first parameter (Book book) tells Spring: "When resolving the author field on a Book, give me the parent Book object."

The key insight: @SchemaMapping methods are only called when needed. If the client's query doesn't include author, this method never executes. That's lazy resolution in action.

Checkpoint: What We've Built So Far

Before we test anything, let's make sure the mental model is clear.

Schema → Code Mapping:

GraphQL Schema	Java Code	Notes
`type Query`	`@QueryMapping` methods	Entry points for reads
`type Book`	`record Book(...)`	Domain model
`author: Author!`	`@SchemaMapping Author author(Book book)`	Lazy-resolved field
`id: ID!`	`String id`	GraphQL `ID` maps to `String`
`pageCount: Int`	`Integer pageCount`	Nullable in schema → `Integer` (not `int`)

The Resolution Flow:

Client sends a query to /graphql
Spring matches bookById to @QueryMapping public Book bookById(...)
If the query includes author, Spring calls @SchemaMapping public Author author(Book book)
If the query omits author, that method is never invoked

This is the "client knows best" philosophy in action. The server doesn't decide what to return—it reacts to what's requested.

🧪 Quick Check: Before moving on, can you predict what happens if you:

Query bookById with an ID that doesn't exist?
Query allBooks but only request title—does the author() method run?

Hold those predictions. We'll test them in a moment.

Step 5: Enable GraphiQL (The Interactive Playground)

GraphiQL is an in-browser IDE for exploring GraphQL APIs. It provides auto-completion, documentation browsing, and query history. Essential for development.

Add to src/main/resources/application.properties:

# Enable GraphiQL playground
spring.graphql.graphiql.enabled=true

# Optional: customize the path (default is /graphiql)
# spring.graphql.graphiql.path=/playground

# Optional: show schema in GraphiQL
spring.graphql.schema.printer.enabled=true

Step 6: Run and Test

Start the application:

./mvnw spring-boot:run

Or from your IDE, run the main class.

Open your browser to: http://localhost:8080/graphiql

You should see the GraphiQL interface. Now let's run some queries.

Query 1: Get a book with minimal fields

query {
  bookById(id: "book-1") {
    id
    title
  }
}

Response:

{
  "data": {
    "bookById": {
      "id": "book-1",
      "title": "Harry Potter and the Philosopher's Stone"
    }
  }
}

Notice: We didn't ask for author, so the author() method in our controller was never called. No unnecessary database hits.

Query 2: Get a book with author details

query {
  bookById(id: "book-1") {
    id
    title
    pageCount
    author {
      firstName
      lastName
    }
  }
}

Response:

{
  "data": {
    "bookById": {
      "id": "book-1",
      "title": "Harry Potter and the Philosopher's Stone",
      "pageCount": 223,
      "author": {
        "firstName": "Joanne",
        "lastName": "Rowling"
      }
    }
  }
}

Same endpoint. Different data. Client decides.

🧪 Try this yourself: Before moving on, modify the query above to only request pageCount. Notice what happens—you get exactly what you asked for, nothing more. Now add author { firstName } back in. Watch how the response shape changes based purely on your query.

Query 3: Get all books (with selective fields)

query {
  allBooks {
    title
    author {
      lastName
    }
  }
}

Response:

{
  "data": {
    "allBooks": [
      { "title": "Harry Potter and the Philosopher's Stone", "author": { "lastName": "Rowling" } },
      { "title": "Moby Dick", "author": { "lastName": "Melville" } },
      { "title": "Interview with the Vampire", "author": { "lastName": "Rice" } },
      { "title": "The Great Gatsby", "author": { "lastName": "Fitzgerald" } },
      { "title": "Clean Code", "author": { "lastName": "Martin" } }
    ]
  }
}

Query 4: Multiple queries in one request

query {
  potter: bookById(id: "book-1") {
    title
  }
  cleanCode: bookById(id: "book-5") {
    title
    author {
      firstName
      lastName
    }
  }
}

Response:

{
  "data": {
    "potter": {
      "title": "Harry Potter and the Philosopher's Stone"
    },
    "cleanCode": {
      "title": "Clean Code",
      "author": {
        "firstName": "Robert C.",
        "lastName": "Martin"
      }
    }
  }
}

Two queries, one HTTP request. Aliases (potter:, cleanCode:) let you query the same field multiple times with different arguments.

What Just Happened?

Let's reflect on what we built and why it matters.

The REST Equivalent Would Have Been:

GET /api/books/book-1                    → Full book object (whether you need it all or not)
GET /api/books/book-1?include=author     → Custom query param handling
GET /api/books/book-1/author             → Separate endpoint for author
GET /api/books                           → All books (hope you don't need authors too)
GET /api/books?include=author            → More custom handling

Five endpoints (at minimum), plus decisions about query parameters, response shapes, and documentation.

With GraphQL We Have:

POST /graphql

One endpoint. The query itself describes what you want. The schema documents what's possible.

The Tradeoffs (Because There Are Always Tradeoffs):

Benefit	Cost
Client flexibility	Learning curve for clients
Self-documenting schema	Schema maintenance burden
No over-fetching	Potential for expensive queries
Single endpoint	Harder to cache at HTTP level
Strong typing	More upfront design work

The N+1 Problem: A Preview

Remember the N+1 problem from the previous article? Our current implementation has it.

If you call allBooks and request author for each, the author() method gets called once per book. Five books = five Author.getById() calls.

In a real application with a database, that's five SQL queries when one would suffice.

The solution? Batching. Spring for GraphQL provides two options: the traditional DataLoader pattern (from GraphQL Java) or the Spring-native @BatchMapping annotation. Both batch those five requests into a single fetch. We'll cover both approaches in the next article.

For now, just know: production GraphQL requires batching. Don't skip it.

Project Structure Recap

bookstore-graphql/
├── pom.xml
└── src/main/
    ├── java/com/example/bookstoregraphql/
    │   ├── BookstoreGraphqlApplication.java
    │   ├── controller/
    │   │   └── BookController.java
    │   └── model/
    │       ├── Book.java
    │       └── Author.java
    └── resources/
        ├── application.properties
        └── graphql/
            └── schema.graphqls

Troubleshooting Common Issues

Symptom	Likely Cause	Fix
`SchemaResourceResolver: No schema files found`	Schema file in wrong location	Must be at `src/main/resources/graphql/schema.graphqls` (note the `.graphqls` extension, not `.graphql`)
`No DataFetcher for field 'bookById'`	Method name doesn't match schema	Ensure `@QueryMapping` method name matches the field name in your schema exactly
`Cannot resolve symbol 'QueryMapping'`	Missing import	Add: `import org.springframework.graphql.data.method.annotation.*;`
GraphiQL shows blank page	GraphiQL not enabled	Ensure `spring.graphql.graphiql.enabled=true` in `application.properties`
`NullPointerException` in `author()` method	Book has authorId with no matching Author	Add null check: `return author != null ? author : null;` or ensure all author IDs have matching entries
Port 8080 already in use	Another app running	Add `server.port=8081` to `application.properties` or stop the other process

What's Next?

This tutorial covered the basics: schema definition, data fetchers, and the mental model of GraphQL resolution. But production GraphQL involves more:

DataLoader and batching — Solving the N+1 problem
Mutations — Creating, updating, and deleting data
Subscriptions — Real-time data with WebSocket
Error handling — Partial responses and error types
Authentication & Authorization — Securing your schema
Testing — Spring GraphQL's testing utilities

If there's interest, I'll continue this series. Let me know in the comments which topic you'd want next.

The Takeaway

GraphQL isn't magic. It's a different way of thinking about data access—one where the client describes what it needs rather than hoping the server guessed correctly.

Spring for GraphQL makes this approachable for Java developers. The annotations feel familiar. The integration with Spring Boot is seamless. And with Java records, your domain models stay clean.

But remember what I said in the philosophy article:

Technologies carry the DNA of the problems they solved.

GraphQL carries Facebook's DNA: complex relationships, mobile-first thinking, and client-driven data needs. If your use case matches, GraphQL is powerful. If you're building simple CRUD APIs for internal services, REST might still be the pragmatic choice.

The skill isn't knowing GraphQL. The skill is knowing when to use it.

Resources

Spring for GraphQL Documentation
GraphQL Java Book by Andreas Marek (the GraphQL Java maintainer)
GraphQL Specification
Source code for this tutorial (coming soon)

Found this useful? Have questions? Drop a comment below. And if you haven't read the philosophy piece yet, start there—it'll make everything here click.

REST vs GraphQL: Two Philosophies, Two Eras, One Endless Debate

dbc2201 — Thu, 08 Jan 2026 20:56:52 +0000

This post is for you if you can answer "yes" to all/most of the questions below:

You've built APIs before (or at least consumed them).
You've heard the "REST vs GraphQL" debate and felt confused about which one is "better."
You're tired of surface-level comparisons that just list features.
You want to understand why these technologies exist, not just how to use them.
You're the kind of developer who asks "why?" before "how?"

If you nodded along, stick around. This isn't another comparison table. This is the story of two philosophies born in different eras, solving different problems, and somehow ending up at the same dinner table in 2026.

The Misconception That Needs to Die

Let me start with something that might hurt: REST was never designed for building APIs.

Wait, what?

I know. I had the same reaction when I first read Roy Fielding's 2000 dissertation properly. As a trainer who's been explaining REST to developers for years, this was humbling.

Consider this: Roy Fielding wasn't some random PhD student who sat in an ivory tower and came up with a bright idea. He was deeply embedded in the web's early development. He co-authored HTTP 1.0 and 1.1. He co-founded the Apache HTTP Server project. The man literally helped build the plumbing of the internet.

REST (Representational State Transfer) was his doctoral dissertation's attempt to describe and formalize the architecture of the World Wide Web itself. The entire web is supposed to be RESTful. REST isn't specifically about JSON APIs or GET /users/123. In fact, Fielding doesn't mention web APIs much in his dissertation at all.

This distinction matters more than most developers realize.

So How Did REST Become the "API Standard"?

Here's where history gets interesting.

In the mid-2000s, developers were burning in SOAP hell. SOAP (Simple Object Access Protocol) was verbose, complicated, and required understanding a maze of XML specifications just to say "Hello World." There's nothing simple about it, by the way.

Developers needed an escape route. They needed their own four-letter acronym to rally behind.

And REST was right there. It was simple. It used HTTP methods everyone already knew. It didn't require a 400-page PDF manual (looking at you, Salesforce's first API). When Ruby on Rails dropped SOAP support in 2007, David Heinemeier Hansson essentially said SOAP was overly complicated, and the migration was on.

The problem? Most of what we call "REST APIs" today would make Roy Fielding cringe. As he clarified in a 2008 blog post:

"A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types."

Most APIs hardcode everything. Your /api/v1/users endpoint with JSON responses? That's not really RESTful in the pure sense. It's just "HTTP-based API that kinda follows some REST principles."

But does that matter? Honestly, not really. What matters is that REST gave us:

Simplicity: HTTP verbs (GET, POST, PUT, DELETE) mapped to CRUD operations
Statelessness: Each request contains everything needed to process it
Cacheability: HTTP caching worked out of the box
A shared vocabulary: Developers worldwide could talk to each other

REST became the lingua franca of APIs. And that's powerful.

Enter Facebook's Mobile Nightmare (2011)

2011, Menlo Park. Facebook had a problem.

Their iOS and Android apps were thin wrappers around mobile web views—and they were failing. Slow load times. Frequent crashes. Users abandoning the app entirely. Mark Zuckerberg would later call this approach "one of the biggest mistakes we've made as a company."

Three engineers—Lee Byron, Dan Schafer, and Nick Schrock—took on the challenge of rebuilding the News Feed as a native iOS app. They hit a wall immediately: the backend was architected for web pages, not mobile clients.

Consider what a single News Feed story contains:

Author name and profile picture
Post content (text, images, or video)
Like count
Comments (each with its own author, timestamp, and content)
Shares (which are themselves posts, recursively containing all of the above)

With a traditional REST approach, loading one story could require:

GET /posts/123
GET /users/456          ← author
GET /posts/123/comments
GET /posts/123/likes
GET /users/789          ← commenter 1
GET /users/101          ← commenter 2
...and so on

On a 2012-era 3G connection, this was death by a thousand round trips.

REST: Multiple Round Trips

GraphQL: Single Round Trip

(To be fair: REST has patterns like embedded resources (?include=author,comments) and sparse fieldsets that can reduce this. But they require deliberate design work—they're not built into the paradigm the way GraphQL's single-query model is.)

They tried the existing internal REST-like API. They tried FQL (Facebook Query Language), their SQL-like query language. But both had the same fundamental problem: the data was relational and graph-like, but the APIs were tabular and rigid.

As Lee Byron put it: "You've got a square-peg, round-hole problem on the server and a round-peg, square-hole problem on the client."

The solution? Stop treating data like tables. Start treating it like what it actually is: a graph.

They called the prototype "SuperGraph." The world would eventually know it as GraphQL.

The Philosophy Difference

This is where it gets philosophical. Bear with me: this is the part that'll actually make you think differently about APIs.

REST's Philosophy: The Web of Resources

REST thinks in resources. Every thing is a thing with an address.

A user is a resource: /users/123
A post is a resource: /posts/456
Comments are resources: /posts/456/comments

You interact with these resources using standard HTTP verbs. The server decides what data you get back. The client adapts.

Think of it like a library catalog system: every book has a unique call number (its URL), you follow standard procedures to borrow or return it (HTTP verbs), and the librarian decides what information goes on the checkout slip (the response). You can't ask for "just the first chapter"—you get the whole book.

This made perfect sense for the web. URLs, HTTP methods, caching—it all mapped beautifully to how browsers worked.

GraphQL's Philosophy: The Client Knows Best

GraphQL thinks in queries. The client describes exactly what it wants, and the server fulfills that request.

query {
  user(id: "123") {
    name
    avatar
    posts(first: 5) {
      title
      likes
      comments(first: 3) {
        text
        author {
          name
        }
      }
    }
  }
}

One request. Exactly the data needed. Nothing more, nothing less.

This made perfect sense for mobile apps. Battery life matters. Bandwidth costs money. Every unnecessary byte is a crime.

The Core Tension

The fundamental difference comes down to this:

Aspect	REST	GraphQL
Who decides the data shape?	Server	Client
How many endpoints?	Many (per resource)	One
Data fetching	Fixed responses	Flexible queries
Versioning	URL-based (`/v1/`, `/v2/`)	Schema evolution (deprecation)
Caching	Built into HTTP	Requires additional tooling

Neither is "better." They're solving different problems with different constraints.

The takeaway: REST asks "what resource do you want?" while GraphQL asks "what data do you need?" That one-word difference—resource vs data—explains almost every architectural decision that follows.

The Evolution: 2012 to 2026

Let's trace how both have evolved, because this is where the story gets rich.

REST's Evolution

2000-2010: The Wild West

REST becomes the anti-SOAP
Everyone interprets it differently
OpenAPI (then Swagger) emerges to bring structure

2010-2020: Maturation

JSON becomes the default (goodbye XML!)
API design best practices solidify
HATEOAS (Hypermedia as the Engine of Application State—the idea that API responses should include links to related actions) remains mostly theoretical
OpenAPI 3.0 standardizes documentation

2020-2026: The Pragmatic Era

REST stops pretending to be "pure"
Hybrid patterns emerge (REST serving GraphQL gateways)
AI-driven systems start consuming REST APIs en masse
REST becomes the stable, boring, reliable choice—and that's a compliment
Spring Framework 7 adds first-class API versioning (September 2025)—more on this below

GraphQL's Evolution

2012-2015: The Secret Years

Built internally at Facebook
Powers iOS app rewrite (August 2012)
Users consume 2x more feed stories than the HTML5 app
Remains internal for 3 years

2015: The Open-Source Moment

Facebook publishes the GraphQL specification
Reference implementation released
GitHub builds their public GraphQL API (2016)
Adoption begins slowly

2017-2020: The Hype Cycle Peak

Apollo GraphQL emerges as the dominant tooling company
Every startup wants GraphQL
"GraphQL replaces REST" becomes the hot take
Reality: most teams struggle with complexity

2020-2024: The Sobering

N+1 query problems become well-known (when a single GraphQL query triggers dozens of separate database calls—one for the parent, plus one for each child)
Security concerns (query depth, complexity attacks) require attention
Teams realize GraphQL needs infrastructure investment
Federation emerges for microservices architecture

The N+1 Problem Visualized:

1 query for users + N queries for each user's posts = N+1 database hits. Solution: DataLoader batches the N queries into 1.

2025-2026: The Maturation

10 years of GraphQL celebrated at GraphQLConf 2025
Apollo Connectors released—REST APIs can now be declaratively integrated into GraphQL schemas
GraphQL Foundation standardizes Federation
MCP (Model Context Protocol) shows early promise for bringing GraphQL to AI agents—still emerging, but worth watching
The "GraphQL vs REST" debate finally calms down

The takeaway: Both technologies matured by acknowledging their weaknesses. REST stopped pretending versioning wasn't needed; GraphQL stopped pretending it was simple. The survivors are the pragmatists.

Where Are We Now? (January 2026)

Let me share some numbers that tell the real story:

REST still dominates: 93% of teams use REST, while 33% use GraphQL (Postman State of the API 2025)
GraphQL production usage has reached 61% among surveyed organizations (Hygraph GraphQL Report 2024)
Enterprise adoption is accelerating: Gartner predicts 60%+ of enterprises will use GraphQL in production by 2027, up from less than 30% in 2024 (The New Stack)
Hybrid approaches are becoming the norm—companies running both report higher satisfaction than those committed exclusively to either

(Note: We're focusing on REST and GraphQL here, but gRPC deserves mention as the third major player—especially for high-performance internal microservice communication.)

Pause for a moment: Based on what you've read so far, which philosophy would you lean toward for a mobile-first e-commerce app? Hold that thought—we'll come back to it.

The Spring Framework 7 Plot Twist

Here's something that dropped in September 2025 that perfectly encapsulates the state of this debate.

Spring Framework 7 (releasing November 2025) added first-class API versioning support. For those of us in the Java/Spring world, this is huge. Rossen Stoyanchev from the Spring team wrote about it, and the irony is thick.

While this is Java-specific, it signals a broader industry shift. NestJS has been moving toward declarative versioning, FastAPI added versioning patterns in recent releases, and even Go frameworks like Gin are seeing community pressure for standardized approaches. The enterprise world is collectively admitting: versioning isn't going away, so let's do it right.

The key insight: versioning has always been REST's Achilles heel. Do you version in the URL (/v1/users)? In a header (API-Version: 1.1)? In the media type (application/vnd.myapi.v1+json)? Everyone has opinions. Nobody agrees. There's no standard.

And guess what Roy Fielding, the creator of REST, says about API versioning? He advises against it.

Yet here's Spring, the enterprise Java juggernaut, adding official versioning support because, as the issue tracker showed, implementing it properly "requires a lot of work."

The Mechanics

The idea is simple: configure your versioning strategy once, then let the framework handle routing based on version metadata. No more hacking URL patterns or writing custom interceptors. The framework treats version as a first-class routing concern, just like HTTP method or content type.

The new ApiVersionStrategy lets you configure versioning once and use it everywhere:

@Configuration
public class WebConfiguration implements WebMvcConfigurer {

    @Override
    public void configureApiVersioning(ApiVersionConfigurer configurer) {
        configurer.useRequestHeader("API-Version");
    }
}

Or in Spring Boot 4, just a property:

spring.mvc.apiversion.use.header=API-Version

Then your controllers become beautifully explicit:

@RestController
public class AccountController {

    @GetMapping(path = "/account/{id}", version = "1.1")
    public Account getAccountV1() {
        // Version 1.1 implementation
    }

    @GetMapping(path = "/account/{id}", version = "2.0")
    public AccountV2 getAccountV2() {
        // Version 2.0 implementation
    }
}

They even added baseline versions ("1.2+") so you can say "this endpoint works for version 1.2 and all future versions until something breaks," reducing the need to duplicate controller methods for unchanged endpoints.

For deprecation? Built-in support for RFC 9745 and RFC 8594 headers (Deprecation, Sunset, Link). The server can actually tell clients "hey, you're using an old version, here's when it dies."

The Philosophical Implication

This is REST admitting something GraphQL advocates have said for years: managing API versions is hard, and most teams do it poorly.

But GraphQL's answer to versioning is fundamentally different: "don't version—evolve." You add new fields, deprecate old ones, but you never break the schema. The query language itself allows clients to request only what they need, so adding fields doesn't break anything.

type User {
  id: ID!
  name: String!
  email: String!
  # New field - old clients just don't request it
  avatar: String
  # Deprecated field - still works, but marked for removal
  legacyId: Int @deprecated(reason: "Use id instead")
}

But here's the reality check: GraphQL's "no versioning" philosophy requires discipline. You can't remove fields easily. You can't rename them. Every change must be additive. And if you've ever worked in a fast-moving team, you know how hard it is to maintain that discipline forever. (This is why mature GraphQL teams use Schema Registries with breaking change detection in CI/CD—the tooling enforces what humans forget.)

REST's Approach	GraphQL's Approach
Explicit versions (`v1`, `v2`)	Schema evolution (deprecation)
Multiple endpoints coexist	Single endpoint, schema changes
Breaking changes are clear	Additive-only changes encouraged
Clients choose their version	Clients adapt to schema

Spring's approach says: "Look, versioning is happening. Let's make it first-class so teams do it well instead of poorly."

Neither is wrong. They're just different philosophies:

GraphQL: "Let's design a system where versioning isn't needed."
REST (Spring 7): "Let's accept that versioning happens and make it painless."

Here's what mature teams are doing in 2026:

REST for public APIs: Simple, documented, universally understood
GraphQL for internal composition: Complex queries, mobile apps, dashboard applications
GraphQL Gateways over REST: Apollo Connectors and similar tools let you keep REST backends while getting GraphQL benefits

As Matt DeBergalis (Apollo CTO) said recently: "What would have been a yearlong rewrite has become a two-day implementation."

So, Which Should You Learn?

If you're asking me as a trainer who has taught both to hundreds of developers, here's my honest answer:

Learn REST first. Not because it's better, but because:

It builds on HTTP fundamentals you need anyway
It's what you'll encounter in 80% of real-world projects
It teaches you to think in resources, which is universally useful
Debugging REST is simpler

Then learn GraphQL. Because:

It will change how you think about data relationships
Mobile and frontend-heavy projects increasingly demand it
Schema-first development is a powerful paradigm
The tooling ecosystem is now mature enough

But most importantly: Learn why they exist. The history matters. The philosophy matters. When you understand that REST was about describing the web's architecture and GraphQL was about solving Facebook's mobile crisis, you stop asking "which is better?" and start asking "which is right for this problem?"

The Real Lesson

After years of teaching this, one insight stands out: technologies are not neutral. They carry the DNA of the problems they were born to solve.

REST carries the DNA of the early web—documents, links, browsers, caching. When your problem looks like that, REST shines.

GraphQL carries the DNA of Facebook's News Feed—complex relationships, mobile constraints, constantly evolving schemas. When your problem looks like that, GraphQL shines.

The mistake is treating them as competing answers to the same question. They're not. They're different questions altogether:

REST asks: "How do we create a simple, scalable way to access resources over HTTP?"
GraphQL asks: "How do we let clients efficiently query complex, interconnected data?"

Both questions are valid. Both have elegant answers. The skill is in knowing which question you're really asking.

Your Turn

I'd love to hear from you in the comments:

What's been your experience with REST vs GraphQL?
Have you ever tried running both in the same project?
What problems did each solve (or create) for you?

And if you're still figuring this out—that's okay. I was too, for years. The best developers I know are the ones who stay curious, keep questioning, and never settle for "because that's how it's done."

Keep learning. Keep building. And remember: the technology is just a tool. The thinking is what matters.

If this helped you understand the REST vs GraphQL landscape a little better, consider sharing it with someone who's asking the same questions. Let's raise the level of discourse beyond "X is dead, Y is the future."

References & Further Reading:

Fielding, Roy. Architectural Styles and the Design of Network-based Software Architectures (2000). Link
Byron, Lee. "Introducing the GraphQL Foundation" (2018). Link
Meta Engineering. "GraphQL: A data query language" (2015). Link
Two-Bit History. "Roy Fielding's Misappropriated REST Dissertation" (2020). Link
GraphQL Foundation. "Federation Documentation" (2025). Link
Stoyanchev, Rossen. "API Versioning in Spring" (2025). Link
Stoyanchev, Rossen. "API Versioning Talk at Spring I/O" (2025). Video

Java's Concurrency Revolution: How Immutability and Virtual Threads Changed Everything!

dbc2201 — Wed, 31 Dec 2025 15:08:32 +0000

Explore how Java 25's virtual threads, Scoped Values, and the shift toward immutability are transforming concurrent programming. Learn what changed, what broke, and how to write modern, thread-safe Java code.

TL;DR — Java 25 Concurrency in 60 Seconds

Topic	Guidance
Virtual Threads	Use for I/O-bound work. Create one virtual thread per task—do not pool them.
`synchronized`	Works correctly in Java 24+. The pinning issue is resolved.
`ThreadLocal`	Replace with `ScopedValue` (finalized in Java 25).
Thread Pools	Use `Semaphore` to limit resource access, not thread pool sizing.
CPU-bound work	Use parallel streams or `ForkJoinPool`. Virtual threads provide no benefit here.
Reactive (WebFlux)	Keep for streaming and backpressure. Use virtual threads for request/response.
Structured Concurrency	Preview in Java 25. Learn `StructuredTaskScope.open()` now.

Quick Start:

// Enable in Spring Boot 3.2+
spring.threads.virtual.enabled=true

// Or use directly
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> blockingIOOperation());
}

Migration Priority:

Enable virtual threads in your framework
Replace ThreadLocal with ScopedValue for context propagation
Add Semaphore limits for databases and external APIs
Remove unnecessary ReentrantLock workarounds from Java 21 era

Terminology Used in This Article

To avoid confusion, this article uses these terms consistently:

Virtual threads: Lightweight threads managed by the JVM (introduced in Java 21, enhanced through Java 25)
Platform threads: Traditional OS-level threads (what Java used before virtual threads)
Carrier threads: Platform threads that execute virtual threads
Pinning: When a virtual thread cannot unmount from its carrier thread during a blocking operation

Prerequisites

This article assumes familiarity with:

Basic Java threading concepts (Thread, Runnable, Callable)
ExecutorService and thread pools
Fundamental concurrency concepts (race conditions, synchronization, locks)
Basic understanding of reactive programming (helpful but not required)

New to Java concurrency? Start with Oracle's Concurrency Tutorial first.

Introduction

Remember the first time you encountered a NullPointerException in production caused by a race condition? That sinking feeling when you realized your "thread-safe" code was not actually thread-safe?

You are not alone. For decades, Java developers have wrestled with the complexity of concurrent programming. Here is the exciting news: Java 25 LTS fundamentally changes the game.

Note: This article covers Java 25 LTS, released September 2025. This is the current Long-Term Support release and the recommended baseline for new production deployments.

A Brief History of Java Threading

When Java 1.0 shipped in 1995, its API contained about a hundred classes. Among them was java.lang.Thread. Java became the first mainstream programming language with direct support for concurrent programming.

Since Java 1.2, each Java thread runs on a platform thread supplied by the underlying operating system. Platform threads have nontrivial costs: they require a few thousand CPU instructions to start and consume a few megabytes of memory. Server applications serving many concurrent requests quickly hit the ceiling of what platform threads can handle—especially when those requests spend most of their time blocking, waiting for database results or downstream services.

The classic remedy was non-blocking APIs and reactive programming. Instead of waiting for results, you register callbacks. This approach works, but the nested callbacks become unpleasant quickly.

Virtual threads offer a better path. With virtual threads, blocking is cheap. When a result is not immediately available, you simply block in a virtual thread. You use familiar programming structures—branches, loops, try blocks—instead of callback pipelines.

In this deep dive, we explore how Java's shift toward immutability—combined with virtual threads, Scoped Values, and Structured Concurrency—reshapes how we think about concurrent programming. Whether you maintain legacy code or start fresh, understanding this evolution is essential.

Why Traditional Java Concurrency Is Hard

Traditional Java concurrency fights against how developers naturally think. Consider this familiar pattern:

public class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public synchronized int getCount() {
        return count;
    }
}

This code compiles. It runs. It even passes most tests. But it hides three problems:

Cognitive overhead — Every field access requires you to ask: "Is this synchronized?"
Scalability limits — The synchronized keyword serializes access, creating bottlenecks under load.
Debugging difficulty — Race conditions appear intermittently. Reproducing them in test environments is often impossible.

The core mistake? Trying to make mutable state safe rather than eliminating mutable state entirely.

Reflection question: Think about your current codebase. How many shared mutable fields exist? How confident are you that every access is properly synchronized?

Java's Immutability Journey

To address these challenges, Java's language architects embarked on a multi-year journey. Rather than adding more synchronization tools, they focused on making immutability easier to express.

Timeline: Java's Concurrency Evolution

Year	Java Version	Feature	Impact
2021	Java 16	Records	Immutable data carriers by default
2021	Java 17	Sealed Classes	Constrained, predictable type hierarchies
2023	Java 21	Virtual Threads	Lightweight threads for I/O-bound work
2024	Java 24	Synchronized Pinning Fix	JEP 491 eliminates `synchronized` pinning
2025	Java 25	Scoped Values (final)	Modern replacement for `ThreadLocal`
2025	Java 25	Structured Concurrency (preview)	Task lifecycle management

Records (Java 16)

Records provide a concise way to create immutable data carriers:

// Before: 50+ lines of boilerplate
public class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }

    @Override
    public boolean equals(Object o) { /* ... */ }

    @Override
    public int hashCode() { /* ... */ }

    @Override
    public String toString() { /* ... */ }
}

// After: One line, inherently thread-safe
public record Point(int x, int y) {}

Records are immutable by design. Pass them between threads without synchronization, without defensive copying, without worry.

Sealed Classes (Java 17)

Sealed classes constrain inheritance. This makes type hierarchies predictable:

public sealed interface PaymentResult 
    permits Success, Failure, Pending {}

public record Success(String transactionId) implements PaymentResult {}
public record Failure(String errorCode, String message) implements PaymentResult {}
public record Pending(String referenceId) implements PaymentResult {}

When you know exactly what implementations exist, reasoning about thread safety becomes tractable.

Enter Virtual Threads

Java 21 introduced virtual threads—lightweight threads managed by the JVM rather than the operating system. Java 25 LTS builds on this foundation with critical improvements.

How Virtual Threads Work

Virtual threads decouple the concept of a "thread" from OS resources:

Your code runs on a virtual thread
The JVM schedules virtual threads onto carrier threads (platform threads)
When a virtual thread blocks (I/O, sleep, lock), it unmounts from its carrier
The carrier can then run another virtual thread
When the blocking operation completes, the virtual thread mounts again (possibly on a different carrier)

// Old approach: Carefully sized thread pools
ExecutorService executor = Executors.newFixedThreadPool(200);
// Hit this limit and requests queue or get rejected

// New approach: Spawn threads freely
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 1_000_000).forEach(i -> 
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return processTask(i);
        })
    );
}
// One million concurrent tasks? No problem.

Performance Comparison

Scenario	Platform Threads	Virtual Threads	Improvement
10K concurrent HTTP calls	45 sec	3.2 sec	14x faster
Memory footprint (10K threads)	~10 GB	~200 MB	50x less
Thread creation time (1K threads)	1,200 ms	12 ms	100x faster
Max concurrent connections	~4,000	~1,000,000+	250x more

Benchmark note: These numbers represent typical results. Your mileage will vary based on workload, hardware, and JVM configuration. Always benchmark your specific use case.

Creating Virtual Threads: All the Options

The Executors.newVirtualThreadPerTaskExecutor() factory is the most common approach, but Java provides several ways to create virtual threads:

Option 1: Virtual Thread Per Task Executor (recommended for most cases)

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<String> result = executor.submit(() -> fetchData());
    return result.get();
}

Option 2: Thread.Builder for Custom Configuration

Use Thread.Builder when you need named threads or a thread factory:

// Create a builder with auto-incrementing names
Thread.Builder builder = Thread.ofVirtual().name("request-handler-", 1);

// Create unstarted thread
Thread t1 = builder.unstarted(() -> handleRequest());
t1.start();

// Or create and start immediately
Thread t2 = builder.started(() -> handleRequest());

// Get a factory for use with other APIs
ThreadFactory factory = builder.factory();

Option 3: Quick One-Off Thread

For demos or simple cases:

Thread t = Thread.startVirtualThread(() -> doWork());

Option 4: invokeAll for Multiple Tasks with Same Result Type

When you have a list of similar tasks:

List<Callable<String>> tasks = urls.stream()
    .map(url -> (Callable<String>) () -> fetchUrl(url))
    .toList();

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<String> results = new ArrayList<>();
    for (Future<String> f : executor.invokeAll(tasks)) {
        results.add(f.get());
    }
    return results;
}

Thread API Behavioral Differences

A virtual thread is an instance of Thread, but it behaves differently in several ways:

Aspect	Platform Threads	Virtual Threads
Thread group	Configurable	Single fixed group (cannot change)
Priority	Configurable (1-10)	Always `NORM_PRIORITY` (5)
Daemon status	Configurable	Always daemon (cannot change)
`getAllStackTraces()`	Included	Not included

Calling setPriority() or setDaemon() on a virtual thread has no effect.

New and Changed Methods:

// Check if thread is virtual
boolean isVirtual = thread.isVirtual();

// Duration-based methods (added in Java 19)
thread.join(Duration.ofSeconds(5));
Thread.sleep(Duration.ofMillis(100));

// Use threadId() instead of deprecated getId()
long id = thread.threadId();

Removed Methods (throw UnsupportedOperationException):

The stop(), suspend(), and resume() methods throw UnsupportedOperationException for both platform and virtual threads as of Java 20. These methods were deprecated since Java 1.2.

Tip: Use LockSupport.parkNanos() instead of Thread.sleep() when you want to avoid catching InterruptedException:
LockSupport.parkNanos(1_000_000_000); // Sleep 1 second, no checked exception

JVM Tuning Options

Control virtual thread behavior with these JVM options:

Option	Default	Purpose
`jdk.virtualThreadScheduler.parallelism`	CPU cores	Number of carrier threads
`jdk.virtualThreadScheduler.maxPoolSize`	256	Maximum carrier threads
`jdk.tracePinnedThreads=short`	—	Print brief pinning warnings
`jdk.tracePinnedThreads=full`	—	Print full stack traces for pinning
`jdk.traceVirtualThreadLocals`	—	Trace ThreadLocal mutations in virtual threads

Example startup command:

java -Djdk.virtualThreadScheduler.parallelism=16 \
     -Djdk.tracePinnedThreads=short \
     -jar myapp.jar

Note: The jdk.tracePinnedThreads option prints only one warning per pinning location in your code. Use JFR for comprehensive pinning analysis.

Common Pitfalls to Avoid

Before diving deeper, learn from these common mistakes. Avoiding them early saves significant debugging time.

Pitfall 1: Pooling Virtual Threads

// WRONG: Do not pool virtual threads
ExecutorService pool = Executors.newFixedThreadPool(100);
pool.submit(() -> {
    Thread.startVirtualThread(() -> doWork());
});

// CORRECT: One virtual thread per task
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> doWork());
}

Why pooling is wrong: Scheduling tasks on virtual threads that are then scheduled on platform threads is clearly inefficient—you add overhead without benefit. And what is the upside? To limit virtual threads to a small number of concurrent requests? Then why use virtual threads at all?

With platform threads, pool sizing was a crude but effective tuning knob. With virtual threads, use Semaphore or other mechanisms to protect specific limited resources instead of capping overall concurrency.

Pitfall 2: Using ThreadLocal for Caching

// WRONG: Creates millions of cached objects
private static final ThreadLocal<ObjectMapper> mapper = 
    ThreadLocal.withInitial(ObjectMapper::new);

// CORRECT: Use a shared immutable instance
private static final ObjectMapper MAPPER = new ObjectMapper();

// ALTERNATIVE: Use a bounded pool for mutable objects
private static final ObjectPool<StringBuilder> POOL = 
    new GenericObjectPool<>(new StringBuilderFactory());

Each virtual thread gets its own ThreadLocal copy. With millions of virtual threads, you exhaust heap memory.

Pitfall 3: Forgetting Resource Limits

// WRONG: Overwhelms the database
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 1_000_000; i++) {
        executor.submit(() -> database.query(sql));
    }
}

// CORRECT: Limit concurrent access with Semaphore
Semaphore dbPermits = new Semaphore(50); // Match connection pool size

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 1_000_000; i++) {
        executor.submit(() -> {
            try {
                dbPermits.acquire();
                try {
                    return database.query(sql);
                } finally {
                    dbPermits.release();
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                throw new RuntimeException("Interrupted while waiting for permit", e);
            }
        });
    }
}

Virtual threads remove JVM limits. External resources (databases, APIs, file handles) still have limits.

Pitfall 4: Expecting CPU-Bound Speedup

// WRONG: Virtual threads provide no benefit here
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 1000; i++) {
        executor.submit(() -> computePrimes(1_000_000));
    }
}

// CORRECT: Use parallel streams or ForkJoinPool for CPU work
IntStream.range(0, 1000)
    .parallel()
    .forEach(i -> computePrimes(1_000_000));

Virtual threads optimize for blocking I/O. CPU-bound tasks gain nothing and may perform worse.

Pitfall 5: Mixing Blocking and Reactive Code

// WRONG: Blocking inside reactive pipeline
Flux.range(1, 1000)
    .flatMap(i -> Mono.fromCallable(() -> {
        return blockingHttpCall(i); // Blocks reactive thread!
    }))
    .subscribe();

// CORRECT: Choose one paradigm
// Option A: Full reactive
Flux.range(1, 1000)
    .flatMap(i -> webClient.get()
        .uri("/api/" + i)
        .retrieve()
        .bodyToMono(String.class))
    .subscribe();

// Option B: Full virtual threads
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(1, 1000).forEach(i ->
        executor.submit(() -> blockingHttpCall(i))
    );
}

Blocking calls starve the reactive scheduler's limited thread pool.

Pitfall Summary

Pitfall	Symptom	Solution
Pooling virtual threads	No performance gain	Use `newVirtualThreadPerTaskExecutor()`
`ThreadLocal` caching	`OutOfMemoryError`	Use shared immutable or bounded pool
No resource limits	Connection exhaustion	Use `Semaphore`
CPU-bound tasks	High CPU, no speedup	Use parallel streams
Mixed paradigms	Thread starvation	Commit to one approach

Reflection question: Review your current thread pool configurations. Are they sized for JVM limits or for external resource limits?

Java 24+ Update: Synchronized Pinning Is Fixed

If you learned about virtual threads from earlier articles or Java 21 guides, note this important change: JEP 491 (Java 24) eliminated the synchronized pinning problem. This improvement carries forward to Java 25 LTS.

What Was the Problem?

In Java 21-23, when a virtual thread entered a synchronized block and performed a blocking operation, it became "pinned" to its carrier platform thread. This negated scalability benefits.

Java 21-23 Compensatory Behavior: In those versions, the virtual thread scheduler would sometimes compensate by starting additional carrier threads. This happened for many file I/O operations and when calling Object.wait(). However, this compensation had limits controlled by jdk.virtualThreadScheduler.maxPoolSize.

What Changed?

The JVM now allows virtual threads to acquire, hold, and release monitors independently of their carrier threads. This is a JVM-level optimization—no code changes required.

// This is now fine in Java 24+ / Java 25 LTS
synchronized (lock) {
    performBlockingIO(); // Virtual thread can unmount!
}

You no longer need to reflexively replace synchronized with ReentrantLock for virtual thread compatibility.

When ReentrantLock Is Still Appropriate

Pinning still occurs when virtual threads call native code via:

Native methods (JNI)
Foreign Function & Memory API callbacks

For these edge cases, ReentrantLock remains appropriate:

private final ReentrantLock lock = new ReentrantLock();

public void callNative() {
    lock.lock();
    try {
        callNativeLibrary(); // Pinning would occur with synchronized
    } finally {
        lock.unlock();
    }
}

Choose ReentrantLock when you need: tryLock(), timed waits, interruptible locking, or native code interactions.

Scoped Values: The ThreadLocal Replacement

Java 25 finalizes Scoped Values (JEP 506)—a modern replacement for ThreadLocal designed for virtual threads.

The Problem with ThreadLocal

// Creates one formatter per virtual thread (potentially millions!)
private static final ThreadLocal<SimpleDateFormat> formatter = 
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

Problems with this approach:

Each virtual thread gets its own copy
Values are mutable—any code can call set()
Lifetime is unbounded—you must manually call remove()
Memory leaks occur if cleanup is missed

Debugging tip: To locate ThreadLocal usage in your application, run with -Djdk.traceVirtualThreadLocals. You will get a stack trace whenever a virtual thread mutates a thread-local variable.

The Scoped Values Solution

private static final ScopedValue<RequestContext> REQUEST_CTX = 
    ScopedValue.newInstance();

void handleRequest(Request request) {
    var ctx = new RequestContext(request.traceId(), request.userId());

    ScopedValue.where(REQUEST_CTX, ctx).run(() -> {
        processRequest();       // Can read REQUEST_CTX.get()
        callDownstreamService(); // Inherited automatically
    });
    // Value automatically cleared when scope exits
}

void processRequest() {
    var ctx = REQUEST_CTX.get(); // Access anywhere in call stack
    log.info("Processing request: {}", ctx.traceId());
}

Comparison: ThreadLocal vs Scoped Values

Feature	ThreadLocal	Scoped Values
Mutability	Mutable (set/get)	Immutable bindings
Lifetime	Unbounded (manual cleanup)	Scoped (automatic)
Virtual thread cost	High (per-thread copy)	Low (inherited)
Memory leaks	Common	Impossible by design
Inheritance	Expensive copying	Zero-cost sharing

Structured Concurrency (Preview in Java 25)

Warning: Structured Concurrency is a preview feature in Java 25. Enable with --enable-preview. The API may change in future releases.

Java 25 previews Structured Concurrency (JEP 505) with a significantly revised API. While still in preview, it represents the future of concurrent task management.

The Core Pattern

// Enable preview: --enable-preview
try (var scope = StructuredTaskScope.open()) {
    Subtask<User> user = scope.fork(() -> fetchUser(userId));
    Subtask<List<Order>> orders = scope.fork(() -> fetchOrders(userId));

    scope.join(); // Wait for all tasks

    return new UserDashboard(user.get(), orders.get());
} // Scope closes: all subtasks guaranteed complete or cancelled

This pattern eliminates:

Thread leaks
Orphaned tasks
Complex error propagation logic
Manual executor management

Using Joiners for Different Policies

// All must succeed—returns stream of results
try (var scope = StructuredTaskScope.open(
        Joiner.allSuccessfulOrThrow())) {
    scope.fork(() -> fetchFromServiceA());
    scope.fork(() -> fetchFromServiceB());
    scope.fork(() -> fetchFromServiceC());

    Stream<String> results = scope.join();
    return results.toList();
}

// First success wins (race pattern)
try (var scope = StructuredTaskScope.open(
        Joiner.anySuccessfulResultOrThrow())) {
    scope.fork(() -> queryPrimaryDB());
    scope.fork(() -> queryReplicaDB());

    return scope.join(); // Returns first successful result
}

API Changes from Java 21-24

Feature	Java 21-24	Java 25
Creation	`new StructuredTaskScope<>()`	`StructuredTaskScope.open()`
Policies	Subclasses (ShutdownOnFailure)	Joiner objects
Join result	`void` + `throwIfFailed()`	Returns result directly
Type	Class	Sealed interface

Framework Integration Guide

Most Java applications use frameworks. Here is how to enable virtual threads in popular frameworks.

Spring Boot 3.2+

# application.yml
spring:
  threads:
    virtual:
      enabled: true

Or configure programmatically:

@Configuration
public class VirtualThreadConfig {

    @Bean
    public TomcatProtocolHandlerCustomizer<?> virtualThreadCustomizer() {
        return protocolHandler -> {
            protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
        };
    }

    @Bean
    public AsyncTaskExecutor applicationTaskExecutor() {
        return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor());
    }
}

Quarkus 3.x

# application.properties
quarkus.virtual-threads.enabled=true

@Path("/orders")
public class OrderResource {

    @GET
    @RunOnVirtualThread
    public List<Order> getOrders() {
        return orderService.findAll(); // Blocking call is fine
    }
}

Micronaut 4.x

# application.yml
micronaut:
  server:
    thread-selection: AUTO
  executors:
    io:
      type: virtual

@Controller("/orders")
public class OrderController {

    @Get
    @ExecuteOn(TaskExecutors.VIRTUAL)
    public List<Order> getOrders() {
        return orderService.findAll();
    }
}

Database Driver Compatibility

Driver	Virtual Thread Ready	Notes
PostgreSQL (pgjdbc 42.6+)	Yes	Fully compatible
MySQL Connector/J 8.1+	Yes	Fully compatible
Oracle JDBC 23c+	Yes	Fully compatible
HikariCP 5.1+	Yes	Use with semaphore limiting
MongoDB Java Driver 4.11+	Yes	Async driver also available

HTTP Client Compatibility

Client	Virtual Thread Ready	Recommendation
`java.net.http.HttpClient`	Yes	Built-in, preferred
Apache HttpClient 5.3+	Yes	Classic API compatible
OkHttp 4.12+	Yes	Fully compatible
Spring RestClient (6.1+)	Yes	New blocking client

Real-World Migration: A Case Study

The Scenario

Application: Order Processing Service

50+ REST endpoints
PostgreSQL database
Redis cache
3 downstream microservice dependencies
Peak load: 5,000 requests/second

Before: Reactive WebFlux

public Mono<OrderResponse> processOrder(OrderRequest request) {
    return validateOrder(request)
        .flatMap(valid -> userService.getUser(request.getUserId()))
        .flatMap(user -> inventoryService.checkStock(request.getItems())
            .flatMap(stock -> {
                if (!stock.isAvailable()) {
                    return Mono.error(new OutOfStockException());
                }
                return paymentService.processPayment(user, request.getTotal())
                    .flatMap(payment -> orderRepository.save(
                        new Order(user, request.getItems(), payment)));
            }))
        .map(order -> new OrderResponse(order.getId(), "SUCCESS"))
        .onErrorResume(OutOfStockException.class, 
            e -> Mono.just(new OrderResponse(null, "OUT_OF_STOCK")));
}

After: Virtual Threads

public OrderResponse processOrder(OrderRequest request) {
    try {
        validateOrder(request);

        User user = userService.getUser(request.getUserId());
        StockStatus stock = inventoryService.checkStock(request.getItems());

        if (!stock.isAvailable()) {
            return new OrderResponse(null, "OUT_OF_STOCK");
        }

        Payment payment = paymentService.processPayment(user, request.getTotal());
        Order order = orderRepository.save(
            new Order(user, request.getItems(), payment));

        return new OrderResponse(order.getId(), "SUCCESS");

    } catch (PaymentException e) {
        return new OrderResponse(null, "PAYMENT_FAILED");
    }
}

Migration Results

Metric	Before (WebFlux)	After (Virtual Threads)	Change
Lines of code	12,450	7,470	-40%
Avg debugging time	45 min	18 min	-60%
New developer onboarding	2 weeks	3 days	-78%
P99 latency	142 ms	138 ms	-3%
Memory usage	512 MB	384 MB	-25%

Key Lessons

Start with non-critical paths—migrate background jobs and internal APIs first
Keep reactive for streaming—WebSocket handlers stayed on WebFlux
Update dependencies—ensure JDBC drivers and HTTP clients support virtual threads
Monitor pinning events—use JFR to identify unexpected pinning
Train the team—one day workshop was sufficient

The migration took 6 weeks for a team of 4 developers. The codebase became dramatically simpler.

Debugging and Observability

Virtual threads change how you debug and monitor applications.

Detecting Pinning with JFR

# Start recording with pinning detection
java -XX:StartFlightRecording=filename=recording.jfr,settings=profile \
     -Djdk.tracePinnedThreads=full \
     -jar myapp.jar

# Analyze with JDK Mission Control
jfr print --events jdk.VirtualThreadPinned recording.jfr

When using -Djdk.tracePinnedThreads, you get stack traces showing where pinning occurs:

...
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) <== monitors:1
...

Important: The -Djdk.tracePinnedThreads option prints only one warning per pinning location in your code. For comprehensive analysis, use Java Flight Recorder and look for VirtualThreadPinned and VirtualThreadSubmitFailed events.

Key JFR Events

Event	Purpose	When to Monitor
`jdk.VirtualThreadStart`	Thread creation	Unusual spawn patterns
`jdk.VirtualThreadEnd`	Thread completion	Lifecycle issues
`jdk.VirtualThreadPinned`	Carrier thread blocked	Performance issues
`jdk.VirtualThreadSubmitFailed`	Scheduler rejection	Overload detection

Thread Dumps

# JSON format shows structured concurrency hierarchy
jcmd <pid> Thread.dump_to_file -format=json threads.json

Troubleshooting Checklist

Symptom	Likely Cause	Investigation
High latency under load	Pinning	Check `jdk.VirtualThreadPinned` events
`OutOfMemoryError`	ThreadLocal abuse	Profile heap for thread-local objects
Connection timeouts	Resource exhaustion	Verify semaphore limits match pool sizes
Stack traces missing frames	Async boundaries	Enable async stack trace in IDE

Decision Guide: When to Use What

Use this consolidated guide to choose the right approach for your use case.

Virtual Threads vs Reactive vs Platform Threads

Use Case	Recommendation	Reason
REST API handlers	Virtual Threads	Simple, readable blocking code
Database queries	Virtual Threads	Natural JDBC usage
HTTP client calls	Virtual Threads	Straightforward error handling
WebSocket streaming	Reactive	Backpressure support
Kafka consumers	Reactive or Structured Concurrency	Event stream processing
Background jobs	Virtual Threads	One thread per job
Real-time analytics	Reactive	Complex event processing
CPU-intensive computation	Platform Threads (ForkJoinPool)	No I/O blocking benefit

synchronized vs ReentrantLock

Scenario	Recommendation
Simple mutual exclusion	`synchronized`
Need `tryLock()` or timeout	`ReentrantLock`
Need interruptible locking	`ReentrantLock`
Native code interactions	`ReentrantLock`
Maximum simplicity	`synchronized`

ThreadLocal vs ScopedValue

Scenario	Recommendation
Request context propagation	`ScopedValue`
Transaction context	`ScopedValue`
Mutable per-thread cache	Avoid; use shared immutable or bounded pool
Legacy library integration	`ThreadLocal` (if required by library)

Testing Virtual Thread Code

Basic Unit Test

@Test
void shouldRunOnVirtualThread() throws Exception {
    var result = new CompletableFuture<Boolean>();

    Thread.startVirtualThread(() -> {
        result.complete(Thread.currentThread().isVirtual());
    });

    assertTrue(result.get(1, TimeUnit.SECONDS));
}

Concurrency Test

@Test
void shouldHandleConcurrentAccess() throws Exception {
    var counter = new AtomicInteger(0);
    int taskCount = 10_000;

    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        var futures = new ArrayList<Future<?>>();

        for (int i = 0; i < taskCount; i++) {
            futures.add(executor.submit(counter::incrementAndGet));
        }

        for (var future : futures) {
            future.get(5, TimeUnit.SECONDS);
        }
    }

    assertEquals(taskCount, counter.get());
}

Scoped Values Test

private static final ScopedValue<String> USER_ID = ScopedValue.newInstance();

@Test
void shouldPropagateScopedValues() throws Exception {
    var capturedValue = new AtomicReference<String>();

    ScopedValue.where(USER_ID, "test-user-123").run(() -> {
        assertEquals("test-user-123", USER_ID.get());

        try (var scope = StructuredTaskScope.open()) {
            scope.fork(() -> {
                capturedValue.set(USER_ID.get());
                return null;
            });
            scope.join();
        } catch (Exception e) {
            fail(e);
        }
    });

    assertEquals("test-user-123", capturedValue.get());
}

Your Action Plan

Step 1: Embrace Immutability First

Before touching threads, make your data structures immutable:

Convert DTOs to Records
Use List.of(), Map.of() for collections
Replace setters with "wither" methods or builders

Step 2: Audit Your ThreadLocal Usage

Search your codebase for ThreadLocal:

Context propagation → Migrate to Scoped Values
Object caching → Consider immutable alternatives or proper pools

Step 3: Review Synchronization

In Java 25, synchronized works fine with virtual threads:

Remove unnecessary ReentrantLock migrations done for Java 21
Keep ReentrantLock where you need its advanced features
Watch for native code interactions (still causes pinning)

Step 4: Experiment with Virtual Threads

Start small:

Thread.startVirtualThread(() -> {
    // Your existing blocking code works here
});

Step 5: Learn Structured Concurrency

Even as a preview feature, understanding this pattern prepares you for Java's future:

// Enable preview: --enable-preview
try (var scope = StructuredTaskScope.open()) {
    var result1 = scope.fork(() -> task1());
    var result2 = scope.fork(() -> task2());
    scope.join();
    return combine(result1.get(), result2.get());
}

Key Takeaways

Immutability is the foundation — Records and sealed classes make thread safety the default
Virtual threads change the economics — Blocking is cheap; shared state is expensive
synchronized works again — Java 24+ fixed the pinning issue
Scoped Values replace ThreadLocal — Finalized in Java 25, designed for virtual threads
Thread pools are for bounding, not scaling — Use semaphores for resource limits
Reactive has its place — Streaming and backpressure, not request/response
Structured Concurrency is the future — Preview in Java 25, learn it now

Practical Summary

Use virtual threads when:

You have many tasks that mostly block on network I/O
You want the familiar "synchronous" programming style without callbacks

Do not use virtual threads for:

CPU-intensive computation (use parallel streams or ForkJoinPool)
Tasks that require thread affinity or native code interactions

Remember:

Do not pool virtual threads—use other mechanisms for rate limiting
Check for pinning with -Djdk.tracePinnedThreads and mitigate if necessary
Minimize thread-local variables; prefer ScopedValue for context propagation

Version History and Compatibility

Feature	Introduced	Finalized	Status in Java 25
Records	Java 14 (preview)	Java 16	Stable
Sealed Classes	Java 15 (preview)	Java 17	Stable
Virtual Threads	Java 19 (preview)	Java 21	Stable
Synchronized Pinning Fix	—	Java 24	Stable
Scoped Values	Java 20 (incubator)	Java 25	Stable
Structured Concurrency	Java 19 (incubator)	—	Preview (JEP 505)

About the Author

I am a Corporate and Technical Trainer specializing in full-stack development, helping engineering students and professionals navigate the software engineering landscape. Connect with me to discuss training programs or to discuss Java.

Beyond the One-Way Mirror: Making Tech Interviews Truly Mutual

dbc2201 — Mon, 14 Jul 2025 06:25:05 +0000

As developers, we've all experienced that familiar interview dynamic: sitting across from someone with a clipboard, answering question after question, while rarely getting the chance to understand the environment we might be joining. It's natural to feel like you're being evaluated without getting to assess in return. But what if we reframed this entirely?

The truth is, interviews should be mutual assessments. You're not just seeking any job—you're looking for the right fit for your career, growth, and daily work life. And the companies interviewing you? They genuinely want to find someone who'll thrive in their environment, not just survive it.

Understanding the Current Reality

Before we dive into solutions, let's acknowledge why interviews often feel one-sided. Many interviewers—even technical ones—are working within constraints we don't always see:

HR professionals may lack deep technical knowledge, but are skilled at assessing cultural fit and communication
Technical team members might be juggling interviews with their regular workload, relying on standardised questions for consistency
Companies often prioritise legal compliance and fairness, leading to more structured approaches
Time constraints mean interviewers focus on what they consider most predictive of success

This doesn't excuse poor interview experiences, but understanding these realities helps us approach the situation more constructively.

The Case for Mutual Assessment

When you ask thoughtful questions during interviews, you're not being confrontational—you're being professional. Consider these benefits:

For You:

Gain insight into technical challenges you'd face
Understand team dynamics and growth opportunities
Assess whether the role aligns with your career trajectory
Demonstrate your analytical thinking and genuine interest

For Them:

Attract candidates who care about fit, not just employment
Showcase their technical strengths and culture
Identify people who'll be engaged and committed
Improve their interview process through feedback

Strategic Questions That Create Dialogue

The key is asking questions that invite conversation rather than create tests. Here are approaches that work:

For Understanding Technical Environment:

"What's a recent technical challenge your team tackled, and how did you approach it?"
"How do you balance maintaining existing systems with building new features?"
"What does your code review process look like?"

For Assessing Team Dynamics:

"How do team members typically collaborate on complex projects?"
"What does professional development look like here?"
"How do you handle knowledge sharing across the team?"

For Gauging Company Maturity:

"What's your approach to technical debt?"
"How do you evaluate and adopt new technologies?"
"What's been your team's biggest learning from a project that didn't go as planned?"

Reading Between the Lines

Pay attention to how questions are received and answered:

Engagement vs. Evasion: Strong teams welcome technical discussions
Specific Examples: Concrete stories indicate genuine experience
Comfort with Challenges: Openness about difficulties shows maturity
Consistency: Aligned answers across interviewers suggest good communication

Addressing Concerns Constructively

"What if they see me as difficult?"
Frame your questions as wanting to understand the environment, not testing them. Most technical professionals appreciate candidates who think deeply about fit.

"What if they can't answer?"
That's valuable information. It might indicate gaps in technical leadership or communication between teams.

"What if it backfires?"
Companies that respond poorly to thoughtful questions might not be places where you'd thrive anyway.

A Balanced Perspective

This approach isn't about "getting back" at anyone or exposing incompetence. It's about creating more authentic, productive conversations that help both parties make better decisions.

Some interviewers might initially be caught off-guard, but this can lead to more genuine discussions about the real work you'd be doing. Others might appreciate the opportunity to showcase their technical environment and team culture.

The Bigger Picture

When more candidates engage in thoughtful dialogue during interviews, it naturally elevates the entire process. Companies begin to see the value in having technically knowledgeable people involved in hiring. HR teams develop better questions and partner more effectively with technical staff. The result is better matches and more satisfied employees on both sides.

Moving Forward

Your interview experience is ultimately about finding a mutual fit. By approaching it as a professional conversation rather than an interrogation, you're more likely to find environments where you'll truly thrive. And in the process, you're contributing to a more mature, respectful hiring culture that benefits everyone in tech.

The next time you're in an interview, remember: you're not just being evaluated—you're being considered too. That's not adversarial; it's professional. Ask your questions, listen carefully, and trust that the right opportunities will welcome your engagement.

Breaking the LeetCode Loop: How Goodhart’s Law Exposes the Pitfalls of Mindless Coding Grinds

dbc2201 — Sat, 22 Mar 2025 14:35:04 +0000

Introduction: The Coding Olympiad Obsession

Walk into any computer science department today, and you’ll hear the same refrain: “How many LeetCode problems have you solved this week?” Undergraduate students worldwide grind algorithmic puzzles day and night, treating coding platforms like digital battlefields. But while mastering algorithms is valuable, this singular focus has spiralled into a counterproductive obsession—one that Goodhart’s Law helps explain, and one that risks leaving students unprepared for real-world software development.

What Is Goodhart’s Law? (And Why Should You Care?)

Coined by economist Charles Goodhart, the principle states:

“When a measure becomes a target, it ceases to be a good measure.”

In simpler terms: Once we optimize for a specific metric (like LeetCode problem counts), we distort its original purpose. Students aren’t alone in this trap—companies like FAANG once prioritized algorithmic interviews but now report frustration with hires who lack practical skills like debugging or API design.

The LeetCode Bandwagon: A Case Study in Misaligned Incentives

The modern CS student’s reality:

Fear-Driven Practice: “If I don’t solve 500 problems, I’ll fail Amazon’s interview!”
Skill Neglect: Git? Databases? IDE shortcuts? “I’ll learn that later…”
Echo Chambers: Peers glorify “hard problem” counts, creating social pressure to conform.

This bandwagon effect mirrors Googhart’s Law perfectly. LeetCode was meant to assess problem-solving skills, but students now treat it as the sole target of their education. The result? A generation of developers who can reverse linked lists blindfolded but struggle to:

Collaborate via version control (Git)
Design RESTful APIs
Optimize database queries
Configure CI/CD pipelines

The Hidden Costs of Algorithm-Only Obsession

1. The “Toy Problem” Trap

LeetCode problems are sanitized, self-contained challenges. Real-world codebases are messy, undocumented, and require:

Debugging legacy systems
Writing maintainable code
Navigating monolithic architectures

2. Tooling Illiteracy

Students memorize for loops but don’t know:

How to use git rebase to clean commit histories
Why indexing matters in SQL databases
How to profile memory usage in IDEs

3. The Innovation Deficit

Endless pattern-matching on coding platforms stifles creativity. Building projects (e.g., a custom API, a CLI tool) teaches systems thinking—a skill no amount of two-pointer problems can replicate.

A Better Path: Rebalancing Your Learning

1. Apply the 70/30 Rule

70% Practical Skills: Build projects using:
- Version control (Git/GitHub)
- Cloud platforms (AWS/Azure basics)
- Databases (SQL + NoSQL)
- APIs (REST/GraphQL)
30% Algorithms: Solve LeetCode strategically—focus on patterns, not counts.

2. Learn Tools, Not Just Syntax

Debug a memory leak in VS Code
Optimize Docker container sizes
Write unit tests with Jest/JUnit

3. Embrace “Unsexy” Skills

Documentation writing
System design fundamentals
Basic DevOps practices

4. Interview Smarter

Companies like Microsoft and Spotify now include:

Pair programming sessions
Take-home projects
Tooling/architecture discussions

Conclusion: Measure What Matters

Googhart’s Law reminds us that metrics are proxies, not goals. Solving 1,000 LeetCode problems won’t make you a great engineer—but understanding how to:

Collaborate via pull requests
Containerize applications
Design fault-tolerant systems

…will. The next time you open LeetCode, ask yourself: “Am I learning to solve problems, or just gaming a system?”

Break the bandwagon cycle. Your future self—and your first engineering team—will thank you.

Call to Action

Git Guru Challenge: Spend a weekend mastering Git (try Oh My Git!)
Build a Micro-Project: Create a CRUD API with authentication + documentation
Join a Hackathon: Prioritize teamwork and tooling over algorithmic complexity

The road to becoming a complete developer starts when you look beyond the leaderboard. 🚀

About the Author

DBC is a software engineer and educator passionate about helping students bridge the gap between academic theory and industry practice. Follow for more takes on pragmatic learning strategies.

#LeetCode #CodingInterviews #GoodhartsLaw #CSStudents #CodeNewbie #SoftwareEngineering #RealWorldCoding #DeveloperSkills #TechEducation #TechCareers #CareerGrowth #ProgrammingTips #ProgrammingCommunity #BreakTheCycle #SoftwareDevelopment #TechBlog

Boosting Your Productivity: Essential IntelliJ IDEA Features and Plugins for Spring Boot Development

dbc2201 — Mon, 10 Feb 2025 07:19:21 +0000

As a Java Spring Boot developer, having the right tools and knowing how to use them effectively can significantly impact your productivity. IntelliJ IDEA, developed by JetBrains, is widely considered one of the most powerful IDEs for Java development. This guide will help you leverage IntelliJ IDEA’s built-in features and essential plugins to streamline your Spring Boot workflow.

🚀 Built-in Features for Spring Boot Development

1️⃣ Spring Initializr Integration

Seamless project creation using Spring Initializr directly from IntelliJ IDEA
Visual interface for managing dependencies
Pre-configured setup for a smooth start

2️⃣ Smart Code Completion

Context-aware suggestions for Spring configurations
Auto-completion for application.properties and .yaml files
Intelligent autowiring suggestions
Spring-specific annotation completions

3️⃣ Spring Boot Run Configuration

Auto-detection of Spring Boot configurations
Easy management of environment variables
Profile switching for different environments
Live reload support via Spring Boot DevTools

🔌 Essential Plugins for Spring Boot Development

1️⃣ Spring Boot Assistant

Quick navigation to Spring Boot endpoints
Configuration properties documentation
Built-in support for Actuator endpoints

2️⃣ Database Tools and SQL

Integrated database console
Schema visualization and entity relationship diagrams
SQL code completion and query execution
Database version control integration

3️⃣ Lombok Plugin

Reduces boilerplate code using Lombok annotations
Seamless code generation for getters, setters, constructors, and more

🔍 Navigation and Refactoring Like a Pro

1️⃣ Code Navigation

Ctrl + Click / Cmd + Click: Jump to method/class definitions
Ctrl + N / Cmd + O: Search for classes quickly
Ctrl + Shift + N / Cmd + Shift + O: Find any file instantly
Ctrl + Alt + B: Navigate Spring Beans effortlessly

2️⃣ Powerful Refactoring Tools

Safe Delete to avoid accidental removals
Extract Method/Variable for cleaner code
Rename across projects with confidence
Move Classes and Packages easily

🛠️ Debugging Made Easy

1️⃣ Advanced Debugging Tools

Conditional breakpoints for precise debugging
Stream debugging to analyze Java Streams
Thread debugging for multi-threaded apps
Memory view to inspect object allocations

2️⃣ Built-in HTTP Client

Send and test RESTful API requests directly in IntelliJ IDEA
Support for environment variables in API requests
Request history tracking
JSON/XML response handling

🔥 Spring Boot Specific Features

1️⃣ Configuration Properties Support

Auto-completion for application.properties and application.yml
Inline documentation for property values
Quick fixes for incorrect configurations

2️⃣ Endpoints Overview

Visual representation of REST endpoints
Request mapping overview for better API understanding
Security configuration visualization
Actuator endpoint inspection

🧪 Testing Support for Robust Applications

1️⃣ Test Generation

Auto-generate test classes with templates
Test coverage analysis
One-click test execution and debugging

2️⃣ Spring Test Support

Built-in support for MockMvc
Profile-specific test configurations
Test context caching for faster test execution

🔄 Version Control Made Simple

1️⃣ Git Integration

Built-in Git operations (commit, push, pull, merge, etc.)
Branch management with interactive rebasing
Conflict resolution tools with side-by-side comparisons
Change tracking with inline annotations

2️⃣ Local History for Safety

Automatic local versioning (even without Git!)
Recover lost changes
Compare file versions easily
View directory history

⚡ Boost Your Productivity with Shortcuts & Tips

1️⃣ Must-Know Shortcuts

Alt + Insert / Cmd + N: Generate code (getters, setters, constructors, etc.)
Ctrl + Space: Basic code completion
Ctrl + Shift + Space: Smart code completion
Alt + Enter: Show intention actions for quick fixes
Shift + Shift: Search everywhere

2️⃣ Live Templates for Fast Coding

psvm: public static void main(String[] args)
sout: System.out.println()
main: Generate the main method quickly
Customize your own live templates for frequent code snippets

🛢️ Advanced Database Tools & JPA Support

1️⃣ Database View

Connect to multiple databases inside IntelliJ IDEA
Schema visualization for better understanding
Query console for executing SQL queries
Export/import data easily

2️⃣ JPA & Hibernate Tools

Generate Entity Relationship Diagrams (ERD) for JPA entities
JPA console for quick queries
Seamless database migrations
Schema synchronization with JPA annotations

📌 Conclusion

IntelliJ IDEA is a game-changer for Spring Boot development. By mastering these features and plugins, you can significantly improve your workflow and efficiency. Here are some key takeaways:

✅ Learn keyboard shortcuts to speed up development

✅ Customize your IDE settings for better usability

✅ Keep your plugins up to date

✅ Explore new features regularly

✅ Use IntelliJ IDEA’s built-in tools instead of external ones when possible

Investing time in learning these tools will lead to increased productivity and cleaner, more maintainable code. 🚀 Happy coding!

🔗 Additional Resources

Embracing Change: How AI Can Enhance Human Potential

dbc2201 — Sat, 08 Feb 2025 12:41:21 +0000

In the early days of computing, our interface with technology was as rudimentary as punch cards—stiff, error-prone, and requiring a steep learning curve. At the time, many were understandably anxious. The fear was palpable: new technologies would eventually render human roles obsolete. But history has a different story to tell.

A Look Back at Technological Transformation

When punch cards were the norm, interacting with a computer meant feeding in rows of holes to dictate every operation. This method, though groundbreaking, was far from user-friendly. Yet, as technology advanced, so did our interfaces. The emergence of keyboards, monitors, and later, the internet, didn’t just replace punch cards—they revolutionized how we worked. What was once a niche task became an entire field of expertise, spawning roles we couldn’t have imagined before.

This transformation wasn’t about the computer taking over human roles but about computers becoming tools that amplified human abilities. We moved from a paradigm of manual, error-prone data entry to one where computers could process vast amounts of data quickly and accurately, allowing us to focus on creativity, strategy, and innovation.

AI: The Next Evolutionary Step

Today, Artificial Intelligence is poised to be the catalyst for the next significant leap in our technological journey. Much like earlier innovations, AI is not here to replace us but to enhance our capabilities. Here’s why:

Augmentation, Not Replacement: AI can handle repetitive and data-intensive tasks, liberating us to concentrate on higher-level thinking. This symbiosis can drive creativity and problem-solving in unprecedented ways.

Creation of New Roles: Just as the personal computer revolution birthed new industries and job roles, AI is expected to open up exciting avenues—ranging from AI ethics and oversight to new kinds of creative and analytical professions.

Enhanced Efficiency and Productivity: With AI managing routine tasks, human workers can focus on strategy, customer engagement, and other areas that require a personal touch—areas where machines simply cannot compete.

Opportunities for Upskilling: As AI takes over mundane tasks, there is a growing need for skilled professionals who can develop, manage, and improve these systems. This shift encourages continuous learning and skill development, positioning workers to thrive in an AI-enhanced environment.

Overcoming the Fear of Change

It’s natural to feel apprehensive when facing rapid change. Yet, history reminds us that the interface through which we interact with technology is always evolving. Instead of resisting this inevitable progress, we should strive to harness it. By embracing AI as an assistant rather than a competitor, we unlock the potential for a future where human ingenuity and machine efficiency work in tandem.

Looking to the Future

The rise of AI is not a signal for the end of human employment but rather an invitation to innovate and explore new frontiers. By accepting AI as a permanent fixture in our technological landscape, we set the stage for exciting developments that can enhance our daily lives, improve business operations, and lead to societal advancements that benefit everyone.

As we stand on the cusp of this new era, it’s crucial to remember that every technological revolution has faced similar skepticism. Just as we once embraced the transformation from punch cards to personal computers, today we must welcome AI—not as a harbinger of doom, but as a powerful ally in our quest to achieve more, think bigger, and live better.

News of RPA cutting down about 10 million jobs in India

dbc2201 — Thu, 17 Jun 2021 10:26:17 +0000

Recently, there has been a lot of commotion in the news where people are talking about "their worst fears coming to reality", "robots taking over the world", etc. The headlines being somewhere like robots forcing companies to cut down on about 10 million jobs, saving them about 7 lakh crore of money in revenues. People are freaking out over it as if their jobs will be gone now and they will be left helpless.

Seems plausible, right? So I wanted to shed some light around the topic, since I'm currently studying RPA professionally as part of my job currently and soon will be teaching other professionals on how to get ready for RPA in their jobs. So, I'm not an "expert" on the subject, but being closely related to the IT industry in India for about 7+ years now, and now seeing RPA in action with my own eyes for some time, I thought I could help clear out the confusions people have about the subject and news.

First of all, RPA (Robotic Process Automation) is basically creating some software (or code) called "robots", which can do some menial, monotonous process for an employee of a company. According to UiPath (a company working extensively with RPA, valued at 1 billion dollars) says this about RPA "RPA is the technology that allows computer software to mimic actions typically performed by humans interacting with digital systems to execute business processes.". Scary, right?

Well, not so much. RPA is currently not at a position where it could be applied to all the jobs of the IT industry in the worlds, or it could possibly take over complete aspects of a person's job. Currently, it is more suited to some specific areas like:

Payroll Processing:

Payroll processing refers to the actions that companies take to pay their employees - keeping track of their presence, of their salaries, bonuses and taxes.
Payroll processing needs manual intervention month after month, every year. An RPA system can be used to extract the details that are required from handwritten time sheets and calculate the pay from their stipulated contracts and pay them as well (by even ordering the necessary bank transactions).
Client Information Updates:

Any organization that has implemented a CRM faces all sorts of related issues - the client-base is spread across many geographies, there are frequent calls to the back-end databases, and updates and changes are coming from all sources.
RPA solutions can process these requests in batches instead of one after the other, reducing the load on the back-end systems and ensuring better performance and data quality across the whole application.
Renewal Process:

Irrespective of industry, the contract renewal process is in general a complex process, but not necessarily due to exceptions and complications, but rather to the number of operations and the synchronization between different departments and systems.
Robots can take over the entire process, starting with the standardized communication with the client, processing the changes, drafting the documents and updating the internal systems accordingly.
Financial Statement Reconciliation:

Financial statement reconciliation covers all the operations (done mostly by the accounting teams) of matching orders, payments, losses, margins, and so on, with accounts and financial statements. It is a common process that an organization needs to manage in order to ensure clean records and reliable financial documents.
This process is well handled by the RPA software robots. Once they are set up, they can seamlessly replace the humans who would have to do these jobs, from the beginning to the end.
Compliance Reporting:

As organizations grow, it becomes increasingly difficult to closely monitor the compliance requirements that each department has to follow: reporting to authorities, complying with the internal procedures, audit requirements, and so on.
Robots can be set up to cover all these needs, with a low error rate and low human intervention.
Customer Complaint Processing:

Irrespective of industry, customer complaints are always on the radar. Their number and substance is an important indicator of the business health and good predictor of the future of the company.
Through RPA, customer complaints can be categorized based on keywords and other criteria, and possible solutions can be suggested to the customers right away. By doing so, the customer complaints can be answered 24 x 7 instead of 8 hours a day and only 5 days a week.

If I were to define RPA, I would RPA is a way of easing up the repetitive parts of a person's job, by creating specialized robots to do it. But it is a long way from actually taking over the job itself. So, people do not need to worry a lot, even if it looks like there are things that you do in the above list, and it could be taken over by a robot, it is not going to happen soon, so you will get some time to potentially upgrade your skills to get a better job.

Hope I was able to help you put your mind at ease, if you would like to know more, please watch these videos

A Simple Roadmap for Java Beginners in 2021

dbc2201 — Thu, 13 May 2021 14:06:00 +0000

This post is for you if you can answer "yes" to all/most of the questions below:

You are an engineering undergrad in a four-year course.
Your major is computer science & engineering.
You are inclined towards programming.
You are thinking about a career in programming.
You have heard about Java from your friends/peers and want to learn it.
You have some form of introduction to the Java programming language but you want to further increase your knowledge.

It is easy to get overwhelmed these days by looking at what other people are doing in the programming field. Considering the variety of low-code/no-code options available out there to "create" software. Being a teacher for about 6-7 years, I've had my fair share of students coming up to me and asking "What should we learn?".

To which, I mostly answer "Well, start with a programming language, and learn it well." Little did I know in the beginning, that this statement mostly does more harm than good to a student who is confused about their career paths, or what choice do they make given the opportunities that they have currently been exposed to.

They (students) then start asking me a plethora of questions that are largely subjective and depend on the student itself. Sometimes, it is also a matter of taking initiative, and/or deciding on a choice and seeing it through, which I have observed is a lacking ingredient in the younger generation these days. The follow-up questions that I then receive are somewhat like this:

Which is the "best" programming language?
Is the "X" programming language better than the "Y" programming language? Why?
Where should I start from?
What all do I need to learn to land a job?
I watched this YouTube video of this generic YouTuber person, will this suffice?
Do I need to purchase an expensive course for this?

It is completely okay if you have had the same question in your mind for some time, I had the same questions myself when I started programming seriously.

As I have experienced, if you're willing to learn Java (since this post was originally about Java) in 2021, your journey from a "beginner" to a "not-a-beginner-anymore" stage will consist of largely 4 stages.

Before we begin exploring things, I would just like to make a disclaimer that a lot of people will tell you otherwise, they'll often come up to you and say "Oh, it's so easy, just do "this", watch this "video", enrol in this course..." which is complete bollocks. Learning a programming language is exactly like learning a new spoken language, your brain needs to remove or at least ignore your previous bias and get used to thinking in terms of the new language. For that, you need to put in a constant effort and hard work. If it were actually that easy as some people say, everyone you know would have been a rockstar developer and we would have been living in a programming utopia, free of problems, (maybe riddled with bugs, lol).

Just remember, what EVERY programming language does is tell a computer what to do!. In the end, everything gets translated for 1s and 0s for your CPU so it does not matter what language you use to "code" your next big app or website! Languages are for the efficiency and benefit of developers, not the computers.

To start I would recommend this book : Java: A Beginner's Guide by Herbert Schildt

1. Syntax and Semantics:

Data Types (The 8 Java Primitive Types)
Variables (The var keyword)
Type Conversion & Casting
Automatic Type Promotion
Arrays
Operators in Java (Arithmetic, Bitwise, Relational, Boolean Logical, Assignment, ? Operator, Operator Precedence)
Control Statements in Java (If, If-Else, If-Else-If, Switch (new and old))
Iteration Statements (While, Do-While, For, For-Each, Nested Loops) [continue, break and labels]
Using Command-Line Arguments in a Java Program
The String class
Varargs [Variable Length Arguments]
Scanner Class, BufferedReader Class

2. Object-Oriented Programming:

Types of Program Units in Java [4 - Class, Abstract Class, Interface, Enum + 1 Record]
Declaring and Using Objects in Methods
Reference Types and Values
Methods (method signature, method types)
Constructors
The this keyword
Overloading Methods
Overloading Constructors
Using Objects (Reference Types) as method parameters and arguments
Using Objects (Reference Types) as return types of methods
Recursion in Java (Call Stack, Tail-Recursion, Head-Recursion)
The static keyword (creating static members in a class)
The final keyword (with a class, with a method, with a member variable of a class)
Nested Classes and Inner Classes
Inheritance in Java (Super & subclasses) [Hierarchies in programs]
The super keyword (calling Super class' members from the subclass)
Types of Hierarchies in Java [Simple, Multi-level, Multiple, Hybrid]
Method Overriding
Abstract Classes and Abstract Members
Interfacing (defining an interface, implementing an interface, nested interfaces, members in an interface, private OR static OR default methods)
Packages in a Java program (CLASSPATH, importing)
Exception Handling (exception types, caught and uncaught exceptions, try-catch, try-finally, try-catch-finally, multiple catch blocks, nested try statements, throw and throws keyword, custom exceptions)
Multithreaded Programming (Java Thread Model, Main Thread, Creating a Thread, Thread class and Runnable interface, multiple threads, sleep() method, thread priorities, using lambda to create a thread, using anonymous class to create a thread)
Enumeration Classes in Java
Type Wrappers (Wrapper Classes in Java)
Boxing and Unboxing
Annotations in Java
Generics in Java (Bounded Types, Wildcard Types, Bounded Wildcards, generic methods, generic constructors, generics with static methods, generic classes, generic interfaces, overloading and overriding in generic methods, Type Erasure, generic arrays)
Lambda Expression (functional interfaces, lambda as arguments, method references)
Stream API (types of methods, common methods from the API)
String Handling (String class constructors, string length, string operations, character extraction, string comparison, searching strings, modifying strings, StringBuilder, StringBuffer)
Classes in the java.lang package

3. Data Structures & Algorithms:

Collections Framework in Java (collection interfaces - List, Set, Deque, collection classes, - ArrayList, LinkedList, HashSet, TreeSet, PriorityQueue, ArrayDeque, using iterators on collections, Iterator class, for-each loop, streams, Custom Collections Classes, Map Interfaces and Map Classes, Vector, Stack, Dictionary, Hashtable, Properties)
Misc - StringTokenizer, BitSet, Optional, LocalDate, LocalTime, LocalDateTime, GregorianCalendar, TimeZone, Locale, Random, Timer, Currency, NumberFormat, StringFormat.

4. Problem Solving:

When you have some decent knowledge of the topics written above, you can try your hands on some problem solving (a.k.a Competitive Programming, CP). Some recommended websites are

TopCoder
CodeForces
CoderByte
Project Euler
HackerRank
CodeChef
Exercism
CodeWars
LeetCode
Sphere Online Judge SPOJ
CodingGame Choose whichever one you like all of them are for the same thing, to help you build up your knowledge of the language. There are some nice books as well which help you learn the basics of Competitive Programming like
Guide to Competitive Programming Learning and Improving Algorithms Through Contests
Java Coding Problems
The The Complete Coding Interview Guide in Java

The intentional order of the sections is 1-2-3-4, although you could do section 4 as per your comfort, you can very well start section 4 after section 2 as well. PLEASE NOTE that this is not the complete list, there is still a lot more to cover, this is just to get you comfortable enough that you could try anything with Java after this. Hope this blog post will help at least some of you!