Forem: Karan Sahani

Spring Boot CRUD Generator v1.1.0 — JPA Relationships, Done Right

Karan Sahani — Sat, 25 Apr 2026 13:36:28 +0000

🔗 Plugin link: https://plugins.jetbrains.com/plugin/29476-spring-boot-crud-generator

I shipped an update to my IntelliJ plugin that fixes something subtle but critical — the way generated Spring Boot code handles JPA relationships.

The plugin has crossed 1200+ downloads, and the feedback pattern was clear:

Everything works fine… until you add relationships.

❌ The Real Problems

1. LazyInitializationException at runtime

Generated mappers were doing this:

entity.getPosts().stream()...

Works in tests.
Breaks in production (outside transaction scope).

2. null IDs in API responses

DTO generator was skipping id completely.

So every response looked like:

{ "id": null, "name": "java" }

Which makes your API… basically unusable.

3. Mapper calling setters that didn’t exist

Inverse @OneToMany relationships were not generated in DTOs.

Result:

Mapper tries → dto.setPostIds(...)
DTO doesn’t have it → ❌ compile error

✅ What v1.1.0 Fixes

✔ ID is always present

Included in DTO
No @NotNull
Marked as NOT_REQUIRED
Server-controlled

✔ Safe toDto() mapping

dto.setId(entity.getId());

First line. Always.

✔ Collections → null (intentional)

dto.setPostIds(null);

Why?

null = not loaded
emptyList() = loaded but empty ❌ misleading

Also avoids LazyInitializationException entirely.

✔ Single relationships → ID only

dto.setUserId(entity.getUser().getId());

No nested objects.
No recursion.
Frontend-friendly.

✔ Import system fixed

No more garbage like:

com.app.entity.entity.User

🧠 Design Philosophy

Most generators try to map everything.

That’s the root problem.

This update follows a stricter rule:

Don’t trigger database access in mappers
Don’t assume relationships are loaded
Don’t generate code that only works in demos

🎯 Result

You get:

Predictable API responses
No lazy loading crashes
DTOs that always match mappers
Code that actually survives real projects

🙌 Final Thought

This isn’t a flashy release.

It’s a correctness upgrade.

The kind that saves hours of debugging later.

If you’re already using the plugin — update it.

If not — now it’s finally safe to use in real-world projects.

Would love feedback 👇

⚡ I Got Tired of Writing the Same Spring Boot Code… So I Built a Generator Inside IntelliJ

Karan Sahani — Thu, 16 Apr 2026 11:35:20 +0000

⚡ I Got Tired of Writing the Same Spring Boot Code… So I Built a Generator Inside IntelliJ

Every Spring Boot project starts the same way.

You create an entity…
and then spend the next hour writing:

Repository
Service
Controller
DTOs
Mappers
Exception handling
Pagination

Nothing difficult.
Just repetitive.

And repetition is where productivity dies.

🤯 The Real Problem Nobody Talks About

It’s not about writing code.

It’s about rewriting the same code again and again:

Same patterns
Same structure
Same logic

And yet…

We still do it manually.

🧠 The Idea

I asked myself a simple question:

What if selecting a class could generate an entire backend layer?

Not boilerplate.
Not templates.

But production-ready code.

⚙️ Under the Hood (The Interesting Part)

Building this inside IntelliJ was way more complex than expected.

🔹 1. Reading Code Like IntelliJ Does (PSI)

You don’t parse Java files manually.

You work with IntelliJ’s PSI (Program Structure Interface):

Detect fields
Identify annotations like @Entity
Extract metadata

Without PSI → nothing works.

🔹 2. Generating Code That Doesn’t Look Generated

Most generators fail here.

They produce:

Ugly code
Poor structure
Hard to maintain

I wanted the opposite:

Code that feels like a senior developer wrote it.

That meant:

Clean layering (Controller → Service → Repository)
DTO separation
Proper naming conventions

🔹 3. Dependency Injection Without Breaking Projects

This turned out to be one of the hardest parts.

You need to:

Detect if dependency already exists
Support both Maven & Gradle
Avoid duplicates
Insert safely inside correct block

A naive approach breaks builds instantly.

So I built logic to:

Scan existing dependencies
Inject only when missing
Keep it idempotent

🔹 4. Optional Security (JWT)

Security isn’t just “add dependency”.

It involves:

Filters
Authentication flow
User + roles
Token handling

And it had to be:

Optional. Clean. Non-breaking.

🔹 5. Supporting Multiple Databases

Different teams → different databases.

So I added dynamic support for:

MySQL
PostgreSQL
MongoDB
H2

Challenge:

JPA vs Mongo are fundamentally different
Configurations vary
Drivers must be injected conditionally

⚡ The Biggest Lesson

Generating code is easy.
Generating safe, usable, production-ready code is hard.

🧩 What This Changed for Me

I stopped thinking like a developer writing code.

And started thinking like:

A developer building tools for developers.

🚀 Why This Matters

This isn’t just about saving time.

It’s about:

Reducing friction
Standardizing architecture
Eliminating repetitive mental load

Because energy should go into solving real problems…
not rewriting CRUD for the 50th time.

💬 Final Thought

The best tools don’t just automate tasks.

They remove unnecessary thinking.

If you’ve ever tried building developer tools,
or struggled with safe code generation…

I’d love to hear your approach 👇