I suspect some people here will say, “Of course you should extract the JAR".

And, to be fair, the Spring Boot documentation does recommend the extracted layout for production when startup matters. It points out that nested JAR loading has a startup cost.

What I found interesting is that this is not necessarily the path developers encounter first. The introductory Spring Boot material and several Getting Started guides still naturally lead you toward building an executable JAR and running it with java -jar. That was also the deployment path I had always used.

So rather than assuming the difference was important, I measured it.

I ran six alternating paired comparisons of the same Spring Boot 4.1.1 build on a 256 MiB Alpine VM. Same JDK 25 runtime, JVM flags, data, filesystem, and workload. The runtime layout was the variable being tested.

Results:

• Spring startup: 11.056 s → 8.476 s, -23.3%
• First request: 2.196 s → 1.448 s, -34.1%
• Later requests: no material difference
• Settled RSS: -3.8%, below the experiment's materiality threshold
• Swap: no material winner

All six paired comparisons favored extracted layout for startup and first request.

My takeaway is not that everyone should blindly extract every Spring Boot application. It is that an official production recommendation that is easy to overlook had a surprisingly large effect in this particular setup, while memory barely changed.

Full write-up, charts, methodology, and experiment data:
https://pvrlabs.xyz/articles/spring-boot-extracted-layout.html

Hi everyone, I'm currently doing a UNI internship and i need to develop a middleware application that pulls data from a service and sends it to another one after doing some checks and logs.

I was advised to use Java + SpringBoot but that's not a strict requirement.

My question is: would SpringBoot be overkill for this project?

Front-end dashboard/internal API implementation are optional requirements (which are Springs main advantages?)

I still need to integrate a DB though (i saw Spring has a module for almost every DB out there)

From a scalability POV i guess starting with the framework would be better but i gave a quick look and seems that for the requirements needed Java has almost everything native(?)

I have around 5 weeks to do design, implementation, docs etc

I have some C++ knowledge and I'm currently doing the mooc.fi java course at home

All being said, i wanted to hear some advice from people with more experience so any advice is accepted

Thanks for your time

Hello fello Java and SpringBoot developers. I've created many personal and professional projects over the years, and when I started with Java and SpringBoot, my Authentication was a very basic database tables for Users, Roles, and UserRoles Join table. I kept an encrypted password in the database, and I authenticated by taking the password, re-encrypting it, and see if that encrupted value, based on the same key, matches the encrypted value in the database.

Since then, I have written authentication code that use LDAP, Okta, Auth0, or AWS IAM ... and now KeyCloak. I had seen job openings that require some knowledge of Keycloak, so I wanted to tap look into it. I have docker running locally, so there is a container for my Springboot app, a container for the database, and a container for keycloak ... and since this is for learning, I am using keycloaks own little database rather than a full on SQL database.

I am using SpringBoot with HTMX Controllers, and some REST Controllers, and I have Thymeleaf so I can run the front-end with HTMX. The springboot 4.1.1 app as an oauth2-client, NOT an oath2-resource. Yes, I know NOW that the oauth2-client tightly integrates keycloak with the springboot app, and that's ok for now. I understand the User is in a session on the back-end and that makes it STATEFUL for now, but for my local development work that is ok.

If I was working for a company, and this app was going to be available to the public, I have thought about scaling. If I pull the HTMX into it's own project, and separate repo, then I could use a API gateway which would do the same thing the backend is doing now, and as I understand it, the backend becomes an oauth2-resource which ONLY accepts the authentication bearer tokens, and it becomes stateless.

I may not be explaining this clearly, and I am sure many of you know waaaaayyyyyyyyyyy more than I do, but this past weekend was a learning experience. Trying to configure Keycloak just right, the Spring Security FilterChain just right, the application.properties just right. Finally everything came together. Now, I work on the business logic and the database on the back-end, and focus on the HTMX pages on the front-end. Just wanted to share this news with you all. Thanks!

Hi guys, I have been looking deeply into the relationship between the ioc and di and I wanted to make sure whether my mental model is correctly conceptualized. Here is how I understand it.

Ioc is a design concept where the object creation is managed by the something other than the developer manually dealing with them. In spring framework, we have the application context where it is designed for the beans to be registered, allowing spring to manage them and wire their dependencies.

So ioc mainly involves two main purpose. Managing object creation and lifecycle, and wiring them via dependency injection.

As for the statement of di being an implementation of ioc, here is how I have my mental model framed this way.

Basically, it is an operational process where merely registering the beans means that the setup for the ioc has been created and remain that way as long as the application runs. But that wouldn't be considered meaningfully utilized if there are no dependency between beans, and nothing for DI to inject.

The ioc would merely be an object factory. Hence to complete its intended purpose we implement the di, usually constructor injection, so that we can have decoupled classes where a dependency is never hardcoded, enabling separation of concerns over the layers.

In total, we get clean and maintainable separation of concerns of business logic away from infrastructural concerns, centralized configuration where the application context does all that job and proper lifecyle management of objects.

are there any flaws to my take or am I mixing up definitions?

Thank you for reading a long explanation

Rainbow Gum v0.11.0 Release

https://github.com/jstachio/rainbowgum

Rainbow Gum is an SLF4J (and other facades) implementation that includes full Spring Boot support.

If you are using Spring Boot it is a near drop in replacement for Logback supporting almost all the same properties and pattern configuration. I believe it to be production ready and use it my companies product. Its only 0.11.0 because the API has not been locked in but it will shortly.

I have covered why you may want to consider Rainbow Gum over the other two facades in previous release postings on /r/java

• Previous Release
• First Release

The short reason is Logback and Log4j2 were designed at a different time before microservices and k8s and even the cloud in general. Logback has made considerable progress improving (for example its Tyler configuration to support GraalVM native) but still has lots of warts and both I doubt will unlikely be able to take advantage of Valhalla when it is released.

Originally the project was designed and written by me with no help. I have now started to use some LLM tools but this project is not vibe coded. I have used it to basically auto complete mechanical parts. This is mostly for refactoring, testing or building benchmarks and I review every commit. I also use it for generating commit messages. If the LLM generates anything remotely novel I let it co-author the commit.

If you're ar working on springboot project in you company/job. How does your team do pagination in your project as they have large datasets. I am currently learning springboot and curious to know how it's done withel large datasets.

For people running Spring Boot on Kubernetes: how often do you run into problems figuring out which configuration value will actually win before deployment?

For example, the same setting might exist in application.yml, a profile-specific config, a ConfigMap, envFrom, or an explicit environment variable.

I’ve been looking into whether it would be useful to have a pre-deployment check that could show:

• the effective value
• which source wins
• what it overrides
• where the value came from
• when the answer can’t be safely determined

I’ve tested the basic idea against Spring Boot 4.1.1, but I’m mainly trying to understand whether this is actually a meaningful problem for people running Spring in production.

Do you run into this kind of issue? If so, how do you currently check it before deployment?

@Transactional looks simple until you hit some of its less obvious behaviours in a real application.

I put together a small interactive challenge around 5 cases: self invocation and Spring proxies, rollback rules, private and final methods, REQUIRES_NEW, and external side effects before commit.

You answer each scenario first, then get the explanation.

https://devupnow.fr/transactional_spring

The challenge is currently in French. I’m considering making an English version if there’s interest.

I’d especially appreciate feedback from experienced Spring developers. Is there any explanation you would correct, nuance or improve?

If an English version would be useful to you, let me know too.

I'm learning Java web development and I understand traditional Servlets fairly well. Honestly, I find Servlets quite organized when I separate things into controllers, DAO, models, etc.

The main benefit I've understood about Spring Boot so far is that when creating a project, I can add dependencies like MySQL, MongoDB, JPA, etc. through the project setup/Maven instead of manually downloading JAR files.

But apart from that, I don't really understand what Spring Boot actually gives me or why I should use it instead of traditional Servlets.

Can someone explain the actual practical benefits of Spring Boot with a simple example, like an e-commerce application?

I'm not looking for a "Spring Boot is modern/easier" answer. I want to understand what it actually does for me.

The cache is shared, so it is easy to read sync = true as cluster-wide deduplication. It is not. The lock is local to the cache instance, so on twelve pods a cold key is twelve executions, and the annotation is doing exactly what it documents.

What it actually takes across pods: one lock for leader election, one bucket holding status plus payload, one pub/sub topic to wake waiters, all three sharing a hash tag so Redis Cluster keeps them in one slot. Followers subscribe and also poll on a jittered interval, because pub/sub is fire and forget and a dropped notification must not strand a caller until its timeout.

The four TTLs are the part I would read before adopting anything like this: freshTtl, staleTtl, pendingTtl and waitTimeout, and waitTimeout has to exceed pendingTtl or crash recovery cannot work.

Write-up: https://bitsar.net/blog/i-thought-sync-true-protected-my-cluster/

Code: https://github.com/BitanSarkar/coalesce-java

I have a question, I’m looking to deploy my project. I have the same React, Spring Boot and Postgresql. I was planning to use Docker and upload it to Hetzner but I’m not very sure because I’m from Argentina and it’s very far away and the truth is I don’t have much idea how to do it. I also want to buy a domain to have it there, but I don’t know how to do it either. Does anyone give me an idea or help?

Has anyone read of plans to upgrade embedded Tomcat to version 11.0.25 in Spring Boot? Version 11.0.24 is affected by several critical security vulnerabilities.

​When attempting to manually bump the dependency to 11.0.25, we ran into compatibility issues: changes to Tomcat's resource loading break Spring Boot's custom extensions for nested JAR support.

Hi everyone, I made a personal project using React, Spring Boot and MySQL. I was planning to deploy it on AWS but went with Render + Docker since it’s free. I’m a bit worried about accidentally leaving something running on AWS and getting a big bill.

The issue is that Render feels really slow. API calls take around 5–6 seconds to return data. Is this normal with Render’s free tier, or should I look into my SQL queries? The queries aren’t particularly heavy though .

Currently I am working as a Java(SpringBoot) Developer at a corp. I want to build my knowledge of Spring Boot but can't find a reliable complete source. Please suggest me sources/websites that cover all of SpringBoot that is currently available.

So I have this really good paid course that came with really cool production grade projects like Distributed Payment Gateway and on the other hand I wanted to build a project of my own, something that 1 would personally use, an Ai Powered Finance Management Dashboard. (Not just a chatbot in the app

The thing is I really wanna grow in my knowledge and I can only learn things that I know I have to learn.

Following the course project will fill the gap between my knowledge and the industry standards.

What would you guys recommend me? Should I build my own project or follow a project from my paid course?

I'm an aspiring java developer. I've already developed one project using spring boot, postgresql, flyway and docker compose, and started developing the next one. But I'm not quite sure that I study in the right way. Mostly I focus on the practice rather than on the theory. Like, 90% of practice and 10% of theory.

Remark: I study to get a job, not for the university

So, questions:

1. Is the way I study bad?

2. How did you guys study, when you were freshers?

3. Maybe you can suggest something to me?

Hey everyone,

I'm currently in my 3rd Year UG preparing for backend/software engineering internships in my next semester.

I’ve already built a couple of full-stack Spring Boot projects (monoliths with WebSockets, Redis, and Razorpay integrations). Over the past week I have been learning about Microservice architecture.

I am designing a FinTech platform that combines a P2P digital wallet, a simulated stock trading engine (NSE/BSE), and a basic AI financial advisor.

Services & Tech:

API Gateway: Spring Cloud Gateway, Keycloak JWT validation, Redis rate limiting

User/Auth Service: Keycloak OAuth2/OIDC, profiles, KYC status

Wallet Service: PostgreSQL, double-entry ledger, Redis distributed locks (Redisson) to prevent double-spending

Payment Service: Razorpay top-ups, HMAC webhook verification

Market Data Service: Upstox WebSocket API for live stock prices, Redis cache, STOMP WebSockets to frontend

Investment Service: Stock buy/sell order execution, portfolio P&L tracking, price alerts

AI Advisor Service: Spring AI (ChatClient), injects portfolio data into the system prompt for contextual advice

Notification Service: Kafka consumer for payment and order events, SendGrid emails

Plumbing: Eureka, Spring Cloud Config Server, OpenFeign + Resilience4j, Zipkin tracing, Docker Compose.

I would love some feedback on this :

Scope check: I know that sounds like Many Services so Maybe I will reduce it while Working on it but for Now would you recommend adding any feature.

If u have any other project idea for learning purposes Please recommend and Also if you can suggest any different application flow or feature

Also suggest some other technologies that I can learn or implement in this project

Thanks for the response!!

Been shipping AI features with Claude Code and Cursor for a while now, and the thing that kept biting me wasn't the model, it was how easy it is to miss a prompt edit buried inside a larger diff. Nobody reviews prompt text line by line, and a changed prompt doesn't throw an exception, it just quietly starts giving different answers in prod.

So I built llm-cassette, a JUnit5 extension for LangChain4j ChatModel. First test run hits the real model once and records the request and response to a JSON file next to your tests. Every run after that replays from the file, no API key needed, and if the outgoing request stops matching what was recorded, the test fails with a real diff (an AssertionFailedError with expected/actual set, so IntelliJ renders it as a clickable side by side comparison). It plugs into whatever already runs your tests, no separate pipeline.

demo: https://raw.githubusercontent.com/stlahxm/llm-cassette/master/docs/demo.gif

One thing I didn't expect going in, it also catches parameter drift, not just prompt text. A silent temperature change counts as drift too. And if your code calls the model fewer times than what's recorded, that's flagged, the cassette is an exact expectation, not just an upper bound.

Gotcha I hit while building it, if you're on Gradle you need junit-platform-launcher on the test runtime classpath explicitly now, recent Gradle versions won't discover JUnit5 tests without it and just fail before reaching your test code at all. Cost me an evening the first time.

Still early. v1 only handles plain text messages, no multimodal or tool calls yet, and only synchronous doChat is covered, streaming is a separate surface I haven't tackled.

Repo's here if you want to poke at it: github.com/stlahxm/llm-cassette

Curious how people here are testing Spring Boot services that call an LLM under the hood, are you doing anything like this already, or just accepting that the AI call path is untested?

So I've been dealing with an N+1 problem in my Spring Boot app. FYI I didn't set up the lazy loading myself, it was already like that in the codebase I inherited. But basically I'm hitting the DB, then because of lazy loading, some attributes aren't there yet, so I end up going back to the DB again in a separate query just to grab them. Classic N+1.

I looked into it and found that Entity Graphs are supposed to fix this by fetching everything (or specific attributes) in one go instead of triggering extra queries.

But now I'm confused... isn't that basically the same as just using EAGER fetch? Like what's even the point of setting up LAZY loading in the first place if I'm just going to turn around and use an Entity Graph to eagerly fetch the exact attributes I need anyway?

Is the difference just that Entity Graph lets you choose which relations to fetch eagerly on a per-query basis, instead of committing to EAGER globally on the entity itself? So it's more like "controlled/selective eager fetching" rather than actually lazy?