And much of the confusion and frustration at “Java” is actually because of Spring, or the “enterprise” nonsense making everything unnecessarily complex. You can just… write Java without any of that.
You shouldn’t though, because Kotlin exists, which fixes everything that’s wrong with Java while still being 100% compatible, so even in legacy projects you can mix and match and write new code in Kotlin without needing to rewrite any of the existing Java.
It’s not corporate world, it’s web. Spring de facto is the only modern way to build web services and integrations in Java and Spring comes with DI because it’s the way to build efficient extendable framework.
Micronaut and Vert.X also work, and with Kotlin you unlock that ecosystem as well, for example Ktor. One could argue whether Spring is still a modern framework. It works very well, but there is a lot of “magic” and hard to understand annotations with Spring that make it harder to learn and debug than it could be.
Of course the reality in enterprise environments is that change is often very difficult and such changes are a hard sell when you already have millions of lines of Spring code.
But if you are not locked to Spring, there are better options. DI being build in is another negative to me. Spring does everything, and any project using it becomes a “Spring project”. Which robs you of any choice. If you use Ktor for example, it’s only a library, not a framework, and only does the web component. You choose your own DI library that works for you, you choose your own serialization, you choose your own persistence/database solutions, and you can replace Ktor with something else 3 years down the line, if needed, without touching any of the other parts if the project.
And much of the confusion and frustration at “Java” is actually because of Spring, or the “enterprise” nonsense making everything unnecessarily complex. You can just… write Java without any of that.
You shouldn’t though, because Kotlin exists, which fixes everything that’s wrong with Java while still being 100% compatible, so even in legacy projects you can mix and match and write new code in Kotlin without needing to rewrite any of the existing Java.
It’s not corporate world, it’s web. Spring de facto is the only modern way to build web services and integrations in Java and Spring comes with DI because it’s the way to build efficient extendable framework.
Micronaut and Vert.X also work, and with Kotlin you unlock that ecosystem as well, for example Ktor. One could argue whether Spring is still a modern framework. It works very well, but there is a lot of “magic” and hard to understand annotations with Spring that make it harder to learn and debug than it could be.
Of course the reality in enterprise environments is that change is often very difficult and such changes are a hard sell when you already have millions of lines of Spring code.
But if you are not locked to Spring, there are better options. DI being build in is another negative to me. Spring does everything, and any project using it becomes a “Spring project”. Which robs you of any choice. If you use Ktor for example, it’s only a library, not a framework, and only does the web component. You choose your own DI library that works for you, you choose your own serialization, you choose your own persistence/database solutions, and you can replace Ktor with something else 3 years down the line, if needed, without touching any of the other parts if the project.