rewrite VS Spring Boot

If you're into this sort of thing, there's OpenRewrite[1] for the Java ecosystem.

[1] https://docs.openrewrite.org/

> Spring has gotten so bloated.

I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry.

> Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data.

That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them.

> they don't provide easy upgrade paths between majors versions

That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here.

> and they stop updating vulnerabilities on older major versions.

This is not news. They want you to pay for extended support if you need it.

> No docs on migration.

They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-B...

[1]: https://github.com/openrewrite/rewrite

The issue you may run into when migrating from Spring Boot 2.x to 3.x is the JEE namespace renames. Migrating code from 8 to 17 in my experience hasn't been all that difficult. In most projects, there are no changes to make. However, with the namespace change, you'll probably have to do some planning and testing. If you are migrating a lot of projects, check out Open Rewrite, it may help automate a lot of these upgrades (for both 8 to 17 and Spring Boot versions).

Couldn't OpenRewrite (https://docs.openrewrite.org) do a big part of this manual work?

Openrewrite would probably be a big help, see https://docs.openrewrite.org

In a similar vein there is OpenRewrite which is an open-source project that works in a similar way. It also has a lot of great refactorings already built in, like doing all the grunt work for migrating to JUnit 5, or replacing string concatenation in SLF4J log calls with parameterized formatting.

seems a case for https://docs.openrewrite.org/

https://github.com/openrewrite/rewrite might help

- Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spr...

I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.

https://github.com/spring-projects/spring-boot/pull/39754/co...

If you’re currently running with an earlier version of Spring Boot, I recommend that you upgrade to Spring Boot 2.7 before migrating to Spring Boot 3.0. It minimizes compatibility issues as much as possible.

Okay, we need to build the game? No problem, we will use Spring Boot and Swing!

It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this:

https://github.com/spring-projects/spring-boot/issues/33044

Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic.

An interested reader can decide for themselves:

https://github.com/spring-projects/spring-boot/tree/main/spr...

Explicitly decoding URL query parameters occurs less often because many frameworks, including Spring Boot, handle decoding automatically.

https://aws.amazon.com/lambda/ https://aws.amazon.com/api-gateway/ https://aws.amazon.com/serverless/sam/ https://aws.amazon.com/cloudformation/ https://aws.amazon.com/s3/ https://spring.io/projects/spring-boot https://start.spring.io