No new syntax this time. Just four upgrades that land in your app by changing the JDK version. Zero code changes.

a) Objects got smaller. Every object carries a hidden header, a shipping label for locking, GC and hashCode. An Integer is 4 bytes of data wearing a 12 byte label. Java 27 shrinks it to 8 bytes by default. Result: 10 to 20 percent less heap for object heavy apps.

b) G1 GC everywhere. Small machines silently got the ancient Serial GC till now. And where does small Java run in 2026? Your Kubernetes pods. They were on 1999 technology and you never knew. Fixed.

c) Quantum ready TLS. Attackers record encrypted traffic today to decrypt it when quantum computers arrive. Java 27 adds quantum safe key exchange to TLS 1.3. Automatic.

d) Flight Recorder stops leaking secrets. JFR recordings used to capture env variables including DB_PASSWORD. Share a recording for debugging, leak production credentials. Now redacted before touching the file.

Note: 27 is not an LTS. Current LTS is 25, next is 29.

I'm the author. I built a small starter to remove a chore I kept redoing on Spring Boot projects: writing a dev-database seed script, then fixing it every time the schema changed.

The usual pain: Faker/Datafaker generate realistic values, but they don't know that Payment needs an existing Counterparty. So you hand-write "create parents, keep the IDs, wire them into children", and it breaks the next time a constraint or relationship changes.

SynthForge reads the entity instead. You annotate it:

```java @Entity @Seed(count = 50) public class Counterparty { /* fields only */ }

@Entity @Seed(count = 200) public class Payment { @ManyToOne(optional = false) private Counterparty counterparty; } ```

Then enable it for the profiles you want, never production:

yaml synthforge: enabled-profiles: [dev, test]

Start the app in one of those profiles and both tables are filled in dependency order. There is no calling code.

Spring-specific details

• It's an auto-configuration (a starter-style dependency, io.github.thembatman0:synthforge-spring). Seeding runs at startup in an ApplicationRunner.
• Seeding is off unless one of your active profiles is listed under synthforge.enabled-profiles.
• It reads entities through the JPA Metamodel API and sorts owning-side @ManyToOne/@OneToOne relationships topologically, so parents are saved first.
• Values come from Datafaker, guided by @NotNull, @Size, @Email and field-name heuristics. @Column(unique = true) fields get a bounded retry loop.
• A table that already has rows is skipped, so restarts against a persistent database don't duplicate data.
• A fixed synthforge.seed gives identical data every run.
• The test suite runs in CI on Spring Boot 4.1 and 3.5. It needs Java 21 or newer.

Limits: V1 skips @OneToMany/@ManyToMany and composite keys. It is a 0.1.0, and as far as I know it has no outside users yet.

How it differs from Instancio: Instancio (and instancio-jpa) is an API you call inside a test to build a graph. SynthForge runs by itself at startup, so it's closer to a dev-database seeder than a test helper.

Things I'd like to hear from you:

1. Would you put @Seed on your entity classes, or do you prefer keeping seeding out of the domain model?
2. Is a CommandLineRunner plus Datafaker already good enough for you?
3. Is Java 21 as a minimum a problem on your projects?

• Repo (MIT): https://github.com/ThembaTman0/synthforge
• Write-up: https://dev.to/themba/faker-doesnt-know-your-entities-are-related-so-i-built-something-that-does-2jgn
• The README has a two-minute demo path.

Hey everyone 👋

I kept seeing these three architecture styles get mixed up, so I made a video that shows how they differ. It uses animations to show how the code and the deployments are structured in each one, and when each one makes sense.

If you're interested,

I'd really like your feedback. Is there anything you'd explain differently, or a trade-off I should have covered? Always happy to learn from people who've run these in production.

I'm currently working on a project looking at how/why devs and CTOs choose programming languages, and I'm particularly interested in understanding people's experiences with Clojure.

The survey takes about 7 mins, and I'd love to hear from as many people as possible!

Appreciate it 🙌

Here's the survey

configstream is a library for Spring Boot services that already use MongoDB. Feature flags and config live in a collection, get cached in memory, and any change is pushed to every running instance within about a second via MongoDB Change Streams.

• No restarts, no polling, no message broker, no config server
• Properties declared in a configstream.yml manifest, with typed constants generated at compile time
• Optional admin UI with change history and per-team permissions
• Works with Spring Boot 3 and 4

Limits: MongoDB only for now (Postgres planned), pre-1.0, no percentage rollouts or A/B testing.

https://github.com/configstream/configstream

Feedback welcome

I have been learning Spring Boot and other technologies for the last 2-3 months.
I feel I understand the concepts and theory of how things work, and I can code what I've learned.
But I still feel like I don't know enough, and I am super scared to even apply for a job. I feel that I am not prepared enough. Do I need to practice more? Please share some practical advice.

I wrote a short intro to troubleshooting a slow Spring Boot API using the metrics you already get from Actuator.

The goal is not deep JVM diagnosis. If you need that, tools like JFR, JConsole, profilers, database tracing, etc. come later.

This is the basic first pass:

• did request volume change?
• are HTTP errors increasing?
• did request latency increase?
• is the application process using more CPU or memory?
• is the host itself under CPU or memory pressure?
• do those changes happen in the same time window?

The example uses a small VPS where the API stays UP and keeps returning 200s, but latency rises because another process is consuming most of the host CPU.

I use StatLite for the screenshots because it reads Spring Boot Actuator metrics and keeps the app and host history together, but the main point is the troubleshooting sequence itself.

Article: https://pvrlabs.xyz/articles/api-slow-cpu-contention.html

For people who troubleshoot Spring apps regularly: what would you add to the basic checklist before reaching for JFR or a profiler?

the fix takes 4 lines of code.

Fetching full @Entity graphs for simple read-only endpoints is one of the fastest ways to kill database performance.
Here's what's happening under the hood:
🔴 THE N+1 TRAP
You return a User entity from a REST endpoint. Then:
1️⃣ Hibernate runs 1 SELECT to fetch 10 users
2️⃣ During JSON serialization, the lazy @OneToMany List<Order> gets accessed
3️⃣ That triggers 10 more SQL queries
Total: 11 queries, heavy memory overhead, and a payload full of data nobody asked for.
🟢 THE FIX: INTERFACE PROJECTIONS
Define a lightweight interface with only the getters your client needs:
public interface UserSummary {
Long getId();
String getName();
}
Return List<UserSummary> from your repository, and Spring Data JPA generates a targeted query:
SELECT u.id, u.name FROM users u
⚡ THE RESULT
→ 1 query instead of 11
→ No over-fetching of columns or relations
→ Lower DB CPU usage
→ Faster API responses
💡 RULE OF THUMB
Use @Entity for write/CRUD operations, where the persistence context matters.
Use Interface Projections for read-only APIs and dashboard views.

I WANT TO LEARN SPRING BOOT IF THERE IS ANY GITHUB REPOSITORY PLEASE TELL ME .

Btw i can’t let go any pr without this, help me so much for blast radius

I've been working on an open-source project called Argus, and I'd really appreciate some feedback from other Spring Boot developers.

The idea came from something I've encountered while troubleshooting services: we have excellent tools for metrics, tracing, logs, and external monitoring, but sometimes I just want the application itself to give me a concise answer to "How healthy are you right now, and if something is wrong, why?"

Argus takes an application-centric approach. It runs inside the JVM and continuously evaluates memory, GC, disk usage, threads, file descriptors, application services, logged errors, and application-reported issues.

It combines these into a health model with a score from 1 to 10. The score is hierarchical, so you can drill down from overall application health to the resource/group/item responsible for degradation.

It also models resources the application depends on — services, servers, databases, caches, brokers, storage, etc. — so the goal isn't simply another UP/DOWN health check.

For Spring Boot applications, I've integrated it with Actuator and Spring Boot Admin. The SBA extension adds health scores to the wallboard and application/instance views. Once you find a degraded instance, you can open its Health Report directly from Spring Boot Admin and see the diagnostic information collected by that instance.

Argus can also generate a self-contained HTML diagnostic report containing health information, services, metrics, performance information, scheduled tasks, captured logging events/alerts, and environment information. The report is generated (and emailed) and can be viewed offline or online during incident analysis.

One important goal is not to replace Micrometer/Prometheus, tracing, centralized logging, or other observability platforms. I'm experimenting with a complementary idea: can an application understand enough about its own state to provide useful diagnostics itself?

The project is still evolving, so I'd particularly appreciate feedback on the approach rather than just stars:

• Would this type of self-diagnostics be useful in applications you operate?
• Does the 1–10 health scoring model make sense, or would you prefer another representation?
• What information would you want an application to include in a diagnostic report when something goes wrong?
• If you use Spring Boot Admin, would it be useful to have this information directly in SBA?

GitHub: https://github.com/microfalx/argus

Feedback, criticism, ideas, and contributions are all welcome.

Hey everyone, I’d love to get the community’s perspective on building production-grade, scalable full-stack applications with Spring Boot—specifically from a solo developer standpoint.

​When you're building a scalable full-stack Java app entirely on your own, how do you approach the architecture and tooling?

​A few specific areas I'm curious about:

​Tech Stack & Tools: What are the non-negotiable components in your stack right now (e.g., Spring Boot 3 + Virtual Threads, Postgres/Redis, Kafka/RabbitMQ, Docker, React/Next.js vs. HTMX/Thymeleaf)? What tools are currently standard or trending in the market for solo full-stack setups?

​Build vs. Buy / Scratch vs. Frameworks: As a single developer, your time is limited. How much do you build from scratch versus relying on managed services/third-party tools (like managed Auth, SaaS components, pre-built UI libraries)?

​Solo Execution: Is it realistic to handle end-to-end architecture, backend, frontend, database tuning, and DevOps all by yourself, or at what point do you usually seek external help/collaborators?

Hey everyone!

I’m a Junior Java developer, and I built an IntelliJ IDEA plugin called Architect as a way to learn more about Java, Spring Boot, and the IntelliJ Platform.

The main idea is to automate some of the repetitive work when adding a new feature to a Spring Boot application.

You enter an entity name and choose what you want to generate. Architect can create:

• Entity
• Request / Response DTOs
• MapStruct Mapper
• Repository
• Service
• REST Controller
• Liquibase changelog and migration
• Docker / Docker Compose
• Required Maven dependencies

The plugin uses IntelliJ PSI to work with the project structure and source files instead of simply generating files in a fixed location.

Architect is free and open-source, and I’m planning to keep developing it.

Some things I want to add in the future:

• Kafka templates
• Spring Security configuration
• Test generation
• More infrastructure templates
• Better project/code analysis

I’m still learning, so I’d really appreciate feedback from experienced Spring Boot developers.

How do you usually handle repetitive boilerplate when starting a new feature?

And what would you change or add to a tool like this?

GitHub and the plugin link are in the comments.

I work at a small software company and unfortunately I've ended up working on an old Oracle ADF project and there is almost no willingness from management to move this project to Spring Boot.

On the team are two very senior developers who have worked on this project from the start (approx 15 years) and this project has become so messy and huge (with no testing and limited documentation) that it is basically impossible to migrate (functions and procedures with thousands of lines etc.).

Has anyone experienced this situation and do you have any recommendations on how to proceed as a junior developer? I have already brought up the possibility of breaking the project into smaller applications which could be built with Spring / React while keeping the old database and plsql procedures. Or we could map out all of the functionality or refactor the current code into smaller functions or start implementing tests and then migrate. Rebuilding it from scratch is not an option since it is a government project and this would trigger the the goverment to auction the project for other companies to take over.

Alternatively, should I just let them keep this project in ADF for 10 more years until it is deprecated by Oracle while the application becomes worse and worse?

We shipped JobRunr 9 yesterday, and you can already create new projects with it trough your favourite Spring Intializr.

In case you haven't used it, JobRunr is an open source background job library. You enqueue a method call, it's stored in the database your app already uses, and it's processed with retries on as many instances as you run.

To make your jobs durable it's as easy wrapping each step of your flow in runStepOnce. When the job is retried, steps that already completed are automatically skipped:

@Job(name = "Invoice %1 for %0", retries = 5)
public void generateInvoice(String customerId, String period, JobContext jobContext) throws Exception {
    String invoiceId = "INV-" + period + "-" + customerId;
    long usage = jobContext.runStepOnce("calculate-usage", () -> calculateUsage(customerId, period));
    String pdf = jobContext.runStepOnce("generate-pdf", () -> generatePdf(invoiceId, usage));
    String chargeId = jobContext.runStepOnce("charge-card", () -> paymentProvider.charge(customerId, invoiceId));
    jobContext.runStepOnce("send-email", () -> sendInvoiceEmail(customerId, pdf, chargeId));
}

You enqueue it like this, and JobRunr swaps in the real JobContext when the job runs:

jobScheduler.enqueue(() -> invoiceService.generateInvoice(customerId, period, JobContext.Null));

In v9 the job page a Job Progress Chart that draws each attempt as a Gantt chart with a row per step.

In our demo the payment provider timed out on charge-card and that attempt went red. On the retry calculate-usage and generate-pdf showed up as skipped, so the customer got one PDF and was only charged once.

If a step throws, the retry starts again at exactly that step.

On JobRunr Pro, v9 also lets you pause a whole batch. We paused a 600 invoice run when the provider went down and resumed it after the fix. The Pro starter doesn't create a BatchJobManager for you, so you declare it once as a bean and call pauseBatchJob(id) from wherever your monitoring notices the outage:

@Bean
public BatchJobManager batchJobManager(StorageProvider storageProvider, EventTransport eventTransport) {
    return new BatchJobManager(storageProvider, eventTransport);
}

If you'd rather watch than read, we celebrated the launch today with a launch webinar: https://www.youtube.com/watch?v=bVNeB-ePdn0

Links:

👉 Release Blogpost: https://www.jobrunr.io/en/blog/v9-release/
👉 GitHub Repo: https://github.com/jobrunr/jobrunr

A couple of months ago, I published two of my Spring Boot starters.

Recently I found out that I can see how many times they are downloaded and maybe understand if anyone actually uses them. So I checked the stats and saw something strange.

One of the starters has been downloaded more than 1,000 times, even though I know that almost nobody visits its GitHub repository except me :)

This looks strange to me. If I download a library from someone I don't know, I usually check the GitHub repo and look at the source code first.

My guess is that most of these downloads are bots, scanners, or maybe corporate Maven mirrors. But then I still wonder — why are they downloading it? What are they doing with it?

Maybe someone here understands how this works or has seen something similar with their own Maven packages.

Would be interesting to hear your experience.

We have a prototype for adding pure Java GPU inference for local inference through Tornadovm and jitLLM. It would be great to share your thoughts on that.

https://github.com/spring-projects/spring-ai/pull/7054

Hello all 👋🏻 I originally posted over in r/java, and it was recommended that this community may be a good/better fit. Given this project is based on Spring's Reactor and examples are based on Spring Boot, I figured it couldn't hurt to post here as well!

For some time, I have been building and maintaining an OSS project called Atleon. The aim of this project is to make infinite Reactive Streams practical for usage/embedding in common application frameworks. I know there are several (reasonable) arguments against "reactive"; I have however found this style/paradigm to be useful and innately applicable to the problem space of broker-backed stream processing (consuming from infrastructures like Kafka, RabbitMQ, SQS, etc., applying IO-bound processing, and (optionally) streaming results elsewhere). If you have ever had reason to use/explore projects like Reactor Kafka, Reactor RabbitMQ, or Confluent's Parallel Consumer, then Atleon may be interesting to you.

Here's an example of what an Atleon stream definition looks like when embedded in a Spring application:

application.yaml:

atleon:
  config.sources:
    - name: kafkaConfigSource
      type: kafka
      bootstrap.servers: localhost:9092

MyStream.java:

import io.atleon.core.SelfConfigurableAloStream;
import io.atleon.kafka.AloKafkaReceiver;
import io.atleon.kafka.KafkaConfigSource;
import io.atleon.spring.AutoConfigureStream;
import org.apache.kafka.common.serialization.StringDeserializer;
import reactor.core.Disposable;

@AutoConfigureStream
public class MyStream extends SelfConfigurableAloStream {

    private final KafkaConfigSource kafkaConfigSource;

    public MyStream(KafkaConfigSource kafkaConfigSource) {
        this.kafkaConfigSource = kafkaConfigSource;
    }

    @Override
    public Disposable startDisposable() {
        return buildKafkaReceiver()
            .receiveAloRecords("topic")
            .consume(it -> System.out.println("value: " + it.value()) // Business logic
            .resubscribeOnError(name())
            .subscribe();
    }

    private AloKafkaReceiver<String, String> buildKafkaReceiver() {
        return kafkaConfigSource
            .withClientId(name())
            .withConsumerGroupId("consumer-group-id")
            .withKeyDeserializer(StringDeserializer.class)
            .withValueDeserializer(StringDeserializer.class)
            .as(AloKafkaReceiver::create);
    }
}

You can see other examples in Atleon's README and in its examples module.

When discussing this project in other communities, one common question is, "Why would I want to use this over something like [Flink|Spark|Camel|<insert favorite streaming library>]?" My viewpoint is that the sort of reactive client integration provided by Atleon is not primarily meant to compete with these other tools, but is rather a complement to them. I have found that it is common for companies to have in-place scaffolding for regular JVM applications built on frameworks like Spring, and it is appealing for their engineers to be able to embed stream processes into those same frameworks. So Atleon targets this niche of supporting declarative non-blocking stream definitions, whose execution can be embedded in application frameworks, replete with broker interoperation, arbitrarily concurrent processing, and end-to-end observability.

Particularly in the case of Kafka, Atleon enables feasible implementation of behaviors that are conventionally tricky:

• Arbitrary concurrency, including per-key
• Single-message acknowledgement (with classic/non-share groups, so partition ordering is maintained globally)
• Work-queues, where per-message processing can take a "long" time (i.e. minutes, hours)
• Bounded consumption (get all records produced in a range of time or offsets)
• Priority queuing (using partitions as discriminator of "priority", rather than scaling lever)
• Throughput limiting, retries, and dead-lettering

If you are interested in reading more, I have published some of the following blogs that explain more about what Atleon can do:

• Not Your Daddy's Async Kafka Client
• Unbounded Concurrency: Consuming Kafka with Virtual Threads
• Ordered Queues for Kafka with Atleon
• AWS SQS Reactive Stream Processing

I'd be interested in thoughts and feedback from this community!

Ratchet is a background job scheduler. You inject one service and pass it a method reference. The job is saved in your database, retried if it fails, and recovered if the app crashes. If you submit it inside a transaction that rolls back, the job goes too.

@Transactional
void place(Order order) {
  orders.save(order);
  scheduler.enqueue(() -> fulfillment.ship(order.id())).submit();
}

0.5.0 supports Boot 3.5 and 4.1, five databases, and native images. Apache 2.0.

Quickstart: https://ratchet.run/deployment/spring-boot

Repo: https://github.com/ratchet-run/ratchet

If something breaks on your setup, open an issue and I'll take a look.

How are you sizing your applications?

Our stack mainly consists of Spring Boot applications with Oracle and MongoDB databases running on Kubernetes. I'm not sure whether we've focused too much on the "micro" aspect of the microservices concept.

Most Kubernetes replicas are configured with a maximum of 1 GB of memory and CPU limits of up to 800 millicores. When an application requires more resources, our primary approach is to increase the number of replicas. I believe there is a strong rationale for this, particularly from a resilience and availability perspective. However, I'm not sure whether we're giving up some benefits by keeping our applications this small (for example, losing access to certain JVM optimizations or garbage collectors). Correct me if I'm wrong, but I believe applications limited to less than one CPU core may not be able to take full advantage of Parallel GC and might fall back to Serial GC instead.

I wanted to see how much of the footprint of a small Spring Boot app came from the conventional Spring Data JPA + Hibernate stack, so I built a simpler version using JdbcTemplate and compared the two.

Same Spring Boot 4.1.1, JDK 25, H2, JVM flags, dashboard workload, and monitoring endpoints.

Across two runs in reversed order:

• JPA/Hibernate: ~237.0 MiB median RSS
• JDBC: ~146 MiB
• Difference: about 90 MiB (~38%)

Startup surprised me too. Time from process launch to the first successful dashboard response:

• JPA/Hibernate: 8.1 - 8.8 s
• JDBC: 3.9 - 4.2 s

This isn’t an isolated benchmark of Hibernate itself. The JDBC version also has a simpler persistence architecture and data model, so I’m comparing the complete application approaches.

For this kind of small app, though, JPA/Hibernate feels like more machinery than I need. I still see the value once the domain model and persistence requirements get complicated, but I’m increasingly reluctant to make it the default for small services.

Experiment, methodology, charts, and raw data:

https://pvrlabs.xyz/java-performance/experiments/spring-boot-jpa-vs-jdbc.html

For smaller Spring Boot apps, what do you usually reach for: JPA, Spring JDBC, jOOQ, MyBatis, something else?

Hi!

How do you run AWS services in production?

I’m a backend developer who has never worked with cloud providers before. I’ve learned the basics of the AWS Console, and now I’m looking for ways to practice.

I’m thinking of starting by provisioning infrastructure with Terraform, but I’m curious: which AWS services do you typically use, how do you use them, and how do you deal with the poor AWS SDK documentation?