🔗 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 👇
Top comments (1)
This is a strong update. You fixed the stuff that actually breaks in real projects.
null vs emptydecision is spot on. Most people get this wrongOne thing to watch:
nullfor collections can confuse frontend teams if not documented clearlyOverall, this is the right direction. Less magic, more correctness.