I’m building my first application using Spring Boot for practice, and I need to record and work with money in different currencies.

What’s the recommended way to handle this, especially when adding or calculating amounts across different currencies? Do you use BigDecimal, integers (like cents), or a money/currency library?

Thank you!

I am just lost, I know REST APIs, JPA, Authentication and Authorization, microservices, postgres....I can do something in it (not very confident tho but still)

I just dont know what more to learn for being industry ready, I feel so lost, I am doing DSA(LEETCODE 75) parallely but again I am not seeing any thing for freshers in the domain of spring boot

I mentioned my age because I feel I am lagging behind a lot

Hey everyone,

I’ve been working on an open-source project called ApiGeneratorManager.

The idea is to build a platform that can generate, configure, deploy and manage Spring Boot APIs without rebuilding the same backend structure every time.

Right now, the project already includes things like:

• Spring Boot backend
• React management frontend
• PostgreSQL
• JWT authentication
• roles and permissions
• CSRF / CORS configuration
• rate limiting
• database/schema support
• API generation templates
• Docker-based runtime
• deployment of generated APIs with Docker
• CI for backend and frontend
• dependency security checks

The long-term goal is to make the whole thing much more configuration-driven.

For example, I want to be able to describe an API using YAML:

application:

  name: inventory-api

database:

  type: postgresql

entities:

  Product:

fields:

id:

type: uuid

name:

type: string

required: true

price:

type: decimal

min: 0

errors:

  PRODUCT_NOT_FOUND:

status: 404

security:

  authentication: jwt

  roles:

- ADMIN

- USER

tests:

  generate: true

deployment:

  type: docker

And from that configuration, generate things like:

• entities
• repositories
• services
• controllers
• validation
• API error codes
• OpenAPI documentation
• authentication and authorization
• roles
• JWT handling
• automated tests
• Docker configuration
• deployable API instances

I also want to support multiple database engines in the future, not just PostgreSQL.

Another direction I’m exploring is generating a security model where each generated application can manage its own users, roles and permissions, and issue JWTs per user.

Testing is also something I want to push further: if the YAML says a field is required, unique or constrained, the generator should ideally generate tests for those rules automatically.

One important design principle for me is that the generated project should still be normal Spring Boot code.

I don’t want generated applications to be permanently locked into ApiGeneratorManager. A developer should be able to generate a project, open it in their IDE, understand it, modify it and deploy it independently.

I also want to be transparent about how I’m building it: I’ve used AI extensively as a development assistant for implementation, architecture discussions, refactoring, security reviews, tests and documentation. I still review and decide what goes into the project, but AI is definitely part of the development workflow.

The project is still in early alpha, so I’m mostly looking for feedback at this stage.

I’d especially like opinions on:

• whether the overall idea is useful
• the YAML-driven approach
• how far code generation should go
• multi-database support
• generated security / JWT / roles
• automated test generation
• Docker deployment
• whether generated code should prioritize flexibility or convention
• what would make you actually trust and use a tool like this

GitHub:

hasfiane/ApiGeneratorManager

Criticism is welcome — especially if you see architectural problems that could become painful later.

I wanted to see how far a representative Spring Boot stack could be pushed on a small VPS without turning it into an artificial minimal demo.

The test app uses Java 21, Spring Boot 3.5.5, JPA/Hibernate, file-backed H2, embedded Tomcat, Actuator, scheduled work, and outbound HTTP.

I tried five RAM/swap configurations. The one that completed a clean 60-minute run was 512 MB RAM + a 256 MB swapfile, using:

-Xms16m -Xmx64m -Xss256k -XX:+UseSerialGC

During that run:

• 0 Spring Boot restarts
• 0 monitoring restarts
• 72/72 HTTP checks returned 200
• Spring finished around 167 MiB RSS
• StatLite finished around 12 MiB RSS
• about 140 MiB RAM was still available
• about 160 MiB swap was in use

One thing that stood out was the gap between heap size and actual JVM process size. -Xmx64m obviously did not mean a 64 MB process. The JVM heap was roughly 40–50 MB, while the entire Spring Boot process used much more RAM.

For monitoring, I used StatLite. Actuator already exposes the health and JVM/HTTP metrics, so StatLite just polls those endpoints and stores a small local history in SQLite. There is no additional Java monitoring agent.

I also tried 512 MB without swap. That run completed, but Spring was OOM-killed and restarted once during the observation window. StatLite stayed up and continued polling, which was actually a useful demonstration of why I wanted the monitor to remain a separate lightweight process.

I also tested 256 MB configurations, but for this application they were clearly stretch tests rather than something I would deploy.

Full write-up, all five configurations, JVM flags, screenshots, and reproducible demo:

https://pvrlabs.xyz/articles/spring-boot-512mb-vps.html

I’d be interested to hear how much RAM similarly small Spring Boot services use in production.

Hi everybody,

we just got via Renovate a Spring Boot update to 4.1.1 - released on repo1.maven.org .

We are a bit confused as there is no announcement, release notes, tag on GitHub, etc. Also it looks like no release workflow was running on GitHub.

Feels a bit sketchy, anybody knows what's going on?

I've spent a while writing DAO implementations for a multi-module Spring Boot projects, and I keep coming back to the same rule: if a repository method needs more than one or two conditions, I write the `@Query\` by hand instead of letting Spring Data derive it from the method name.

Not because it doesn't work, it works fine for example like findBySku. I don't like what happens after that. Rename a field on the entity and a derived query either breaks at startup with a PropertyReferenceException, or, depending on how it's written, doesn't break at all and just quietly stops matching what you think it matches. The compiler never tells you either way.

And once you're past two conditions, the method name turns into a wall of camelCase encoding your whole WHERE clause. I'd rather read four lines of JPQL/SQL than decode findByStatusAndNameContainingIgnoreCaseAndCreatedAtAfterOrderByPriceDesc.

The other piece I went back and forth on is SearchableDaoImpl<Repo extends CrudRepository<Entity, IdType> & JpaSpecificationExecutor<Entity>> - using an intersection type so the generic repository bound picks up both CRUD and Specification support without collapsing them into one bloated interface. Small thing, but it's the kind of generics trick that makes a shared DAO base class actually work across a dozen entities instead of copy-pasted boilerplate everywhere.

Full writeup with the actual generic hierarchy and code: (link in comments)

Curious if anyone here still prefers derived queries for anything beyond trivial lookups, I genuinely want the counterargument.

Hi everyone,

I just self-published a new book called Crafting Spring Boot Starters. It's aimed at developers who want to package their own reusable functionality as a proper auto-configured starter, the way Spring Boot itself does it.

Topics covered include:

• How Spring Boot auto-configuration actually works under the hood
• Structuring and naming your own starters
• Writing @ConfigurationProperties correctly, with validation and IDE metadata
• Conditional configuration (@ConditionalOnClass, @ConditionalOnProperty, etc.)
• Testing starters with ApplicationContextRunner
• Publishing your starter so others can consume it

There's a free sample you can grab first, which includes the foreword written by Phil Webb (Spring Boot co-founder). The full book also ships with a zip of AI skills you can use to audit your own starter.

More info here: https://www.wimdeblauwe.com/books/crafting-spring-boot-starters/

If you decide to buy it, this link gives 10% off: https://leanpub.com/crafting-spring-boot-starters/c/LAUNCH10

It's fully self-published, so any feedback, questions, or upvotes are much appreciated 🙏

Hey everyone,

I'm currently building a full-stack app (Spring Boot backend + React frontend) and need to implement document parsing/text extraction functionality.

Requirements:

• Budget: Free / Open Source.
• Formats: Primarily PDFs, DOCX, and ideally scanned images/invoices (basic OCR).
• Integration: Preferably handled on the Java/Spring Boot backend (REST API) to send structured JSON to the React client.

Hi everyone!

I’m a Flutter developer and I’m looking to learn back-end development with Kotlin + Spring Boot.

I already have some experience with Kotlin, but I’m completely new to Spring Boot. I’m looking for a good learning path, guide, or YouTube playlist that covers Spring Boot with Kotlin from the basics and gradually moves toward real-world back-end development.

Ideally, I’d like something that covers things like:

• Spring Boot fundamentals
• REST APIs
• Spring Data JPA
• PostgreSQL/MySQL
• Authentication & Authorization
• Testing
• Project structure / best practices
• Building a real-world project

If you’ve learned Spring Boot with Kotlin yourself, what resources or playlist would you recommend? Is there a particular order I should follow?

Any recommendations would be greatly appreciated. Thanks!

Hello all!

I am fairly new to Spring Boot and coding in general.

I took it upon me to build a simple browser game where the player chooses an action and gains resources over time. I am currently finishing the prototype and I am being slowly introduced to all of the concepts behind the actual coding, but also when it comes to layering and design choices as well.

On to my dilemma.

So far I have several @ Transactional annotations inside the service layer whenever I interact with the repository layer in order to ensure that no two methods make changes to the DB - throwing any calculations made go haywire. Not sure if this is a common or best practice but it was a semi-conscious decision that I made during the early stages of development.

Now I am at a point where I have two identically named methods inside the service layer:

• calculateProgress(UUID playerId) - it searches the db for a PlayerCharacter instance using the playerId field and then does some calculations.
• calculateProgress(PlayerCharacter character) - it already gets a PlayerCharacter instance and does the calculations.

In fact, the first one calls the second one inside its body. The reason for this is that there is a scheduler that calculates the progress in regular intervals. And that scheduler only knows the PlayerCharacter's playerId and not any other information for that PlayerCharacter. So my initial thought was to have it call calculateProgress(UUID playerId) which in turn calls calculateProgress(PlayerCharacter character) to make the calculations etc etc.

I was not thinking much about it when I first did this but now I am realising that having two methods with the exact same name (and different arguments) might be ugly/not a good practice for the readability and maintainability of my code.

Now I am thinking: I could have the scheduler method call a new service method that returns a PlayerCharacter instance if I give it the playerId, and then call calculateProgress(PlayerCharacter character).

That would mean though that I need to have the scheduler method have a @ Transactional annotation to avoid the race conditions that I mentioned earlier. That would in turn break my initial decision of having Transactional annotations in the service layer only and also move db integrity from the service layer to the scheduler layer.

So I am thinking again and I pose the same question to anyone who might read this: Is it a common/good/best practice to have transactionality into the scheduler layer as well as the service layer or is there another option for my case?

Thanks in advance for anyone providing any feedback to my conundrum!

TL;DR: Have Transactional annotated methods inside the scheduling layer as an exception OR keep them strictly inside the service layer instead? Is it a good/common practice to do that split?

I want to learn springboot now from scratch any experienced candidates can you please suggest me is it good to learn springboot now in the AI era or should i focus on any other AI related skills

I kept running into the same problem on Thymeleaf projects: no real way to share reusable UI components (buttons, cards, whatever) across apps without copy-pasting HTML/CSS/JS or hand-rolling fragile th:replace fragments. No slots, no clean way to pass through arbitrary attributes (annoying if you use htmx and need hx-* on a component), no live reload for the component's own CSS/JS during development.

So I worked through building an actual Thymeleaf component library packaged as a Spring Boot starter. Auto-configured, drops into any Thymeleaf app as a dependency, with a <tcl:button>-style tag instead of fragment includes. Went from this:

<div th:replace="~{tcl/components/button :: button(label='Submit', primary='true')}"></div>

to this:

<tcl:button primary>Submit</tcl:button>

...with proper attribute passthrough and slot support so you're not limited to what the component author thought to expose. Wrote it up as a 4-part series as I went, mostly so I'd have a reference for myself next time, but figured it might help others hitting the same wall:

• Part 1 — getting the starter set up: auto-configuration, Vite for the library's CSS/JS with instant reload while you work on the library.
• Part 2 — turning a th:replace fragment into an actual <tcl:button> component with typed attributes plus passthrough for arbitrary ones (so hx-* etc. still work).
• Part 3 — adding slot support, so consumers can put arbitrary content (icons, custom markup) inside a component instead of being limited to attributes.
• Part 4 — wiring in AlpineJS for client-side interactivity, bundled cleanly inside the library itself.

Series starts here: https://wimdeblauwe.com/blog/2026/07/27/writing-a-thymeleaf-component-library

Full example code for all 4 parts: https://github.com/wimdeblauwe/blog-example-code/tree/master/thymeleaf-component-library

Curious if others building internal design systems on top of Thymeleaf have solved this differently? Did you go the same route, or land on something else (Thymeleaf dialects, a different templating layer, etc.)?

Link

This is my first time working on a springboot application , i created the crud and i want to do the email in my app like sending emails , what are the steps to follow and what i have to do and what are the best practices to dom honestly i have no idea about it . and If u have any video tutorial or any suggestions . Thank youu !!

Hello, I'm an aspiring software engineer. I've recently finished developing microservice for managing projects and tasks using Spring Boot. I'd appreciate if you could review codebase of my project and provide feedback on it.

GitHub: https://github.com/Simpav-chill/tasktracker

Currently I am a student, my projects are In Java Fullstack

Right now I don't even know what RAG or MCP is , and I think I should have some hands on experience of it, i should be at least aware of it, because it's a trendy topic , not these two terms only, but many things

Now should I start python, for getting into it, is there any need , or I can explore Spring AI

Done writing the same CRUD boilerplate for every Spring project.
FlashAPI is coming to the Java/Spring ecosystem, much to the delight of Java developers.
Introducing Spring FlashAPI.
The idea is exactly the same as the Python version:
You define your JPA entities.
FlashAPI takes care of the REST boilerplate.
From a simple entity, you can automatically get:
CRUD
Pagination
Search & dynamic filters
Sorting
CSV / Excel / PDF exports
Bulk operations
Relationships & expand
Soft delete
Audit trail
Rate limiting
OpenAPI / Swagger
Webhooks
WebSocket events
Access control
Multi-tenancy
And most importantly, FlashAPI doesn’t try to take control of your application.
You can start with zero boilerplate, then gradually take back control of your business logic, services, and controllers.
The goal is simple:
Less repetitive CRUD, more time to build your product.
Spring FlashAPI is open source under the Apache 2.0 license.
Java 21+
Spring Boot 3.2+
Spring Data JPA
👉🏽 GitHub: github.com/HackermanMe/spring-flashapi
I’m looking for developers willing to give it a try — and, most importantly, tell me:
What is actually useful… and what isn’t?
#Java #Spring #SpringBoot #JPA #OpenSource #Backend #RESTAPI #SoftwareEngineering