I can only speak for myself, but I was lucky to be exposed to Spring Boot back in the v1.5 days after spending a few years creating Java programs without any framework. No XML at all, configuration by code, and opinionated default configuration that covers most use cases.
The learning curve was not that hard, and I got comfortable with it.
In contrast, I find React, Next.js and other frameworks more complex, and it takes a lot longer to be comfortable
Historically an upgrade could cause issues if the code or dependencies used undocumented functionality (like Byte code manipulation) or calls to native code, or the transitions to modules in v9. Upgrades after version 11 should be less "risky" and be easier to argue to management.
From what I can tell, there are 4 main reasons why some don't upgrade.
1. They have legacy software and are afraid of breaking it, sometimes with good reasons.
2. The devs don't know or care enough about the new versions to bother with it. Noone is promoted because of an upgrade. Work to live, and don't live to work
3. The ones who don't have buy in from management to spend time fixing something that works
4. They are using version 11+ that should be much safer to upgrade than earlier versions, but they are still in the mindset of 1 or 2 above
There have been huge improvements not only in the language itself, but also performance and memory use. They could save money if they upgrade, but in some cases this is acceptable because they can make more money by spending time on a new feature, than an upgrade.
In my last 3 workplaces, they usually tried to use the latest LTS versions. But to be honest, some of the services were in maintenance mode and we didn't get enough benefits to upgrade, so we were sometimes falling behind. Today we have a mix of v17 and v21. Anyone can upgrade anytime they want but noone cares about a service that you seldom work with. I feel kind of bad for that, but not enough to bother. I focus mainly on the services that I work with daily, and make sure they are using the latest versions
> That's debatable, and even if we blindly assume that then it's debatable whether the upgrade justifies the gains
This is not debatable. It’s a factual truth. Every single actual performance review concludes that modern Java vastly out performs the decade old Java 8 runtime.
For an example here is a quote from Hazelcast when comparing performance of modern Java on data heavy workloads [0]:
> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses.
This is from 2020 and the gap has only gotten wider.
Java tends to prefer using available memory, before it has to clean it. This results in memory usage growing more than it actually needs.
Services often run in containers, so this is less than a problem today than it was before, because the allocated memory to the container is fixed anyway.
Try configuring the JVM to only use 75% of the container memory. In many cases, it will trigger an early GC and run better with smaller memory instances
There are of course some overhead for objects compared to primitives, but the Valhalla project is working to reduce the difference significantly on many cases.
You can also reduce memory usage and startup time by compiling to a binary image
> you will never see `IntStream` kind of workarounds in C#.
You may not see that in Java in the future either. Java will have value objects from the Valhalla project, and part of the plan is to replace Integer with a value object. Then there will be less of a reason to use raw int primitives, because the JVM can treat value objects much more efficiently than normal objects.
The difference is that C# has been designed with proper generics since version 2 (pushed by F# research group with Don Syme) and is now on version 13. At the same time, structs have been present since version 1.
All APIs and collection types build on this foundation, with standard library leveraging generic monomorhpization for zero-cost abstractions. Code that would have needed C++ implementation in the past is naturally expressed in pure C#. Generics are fully integrated into the type system at IL level, avoiding special-cased types or bespoke compiler handling (besides monomorphization).
This enables numerous zero-cost features: tuples (unnamed/named), structs with controlled mutability and record structs, pattern matching, stack buffers that do not rely on escape analysis, structs with byref pointers for slice types (Span<T> and friends) which a good two thirds of the standard library accepts. Numeric and vector primitives are used in a simple way without setup requirements like Panama Vectors.
While project Valhalla will get Java's foot in the door in some domains, it will remain a less optimal choice than C#, C++, Rust, etc. Java's evolution primarily serves its ecosystem's needs, whereas C# benefits from being a newer language that learned from both Java and C++ and got influenced by F# and other research projects inside MS. This makes C# more idiomatic and terse. The historical drawbacks - platform lock-in, being closed-source, and having relatively weak compiler - have been resolved over the past ~9 years.
I choose Spring Boot anytime I have to create a service, just for that reason.
The eco system is a huge force multiplier, and is constantly evolving. Spring Boot simplifies that a lot by simplifying the setup to the point where you often only have to add a single dependency, and everything is configured with default configurations (which you can change if necessary of course)
One example is the new Spring AI, where they have abstracted a lot of functionality and you can change providers (OpenAI, Mistral, AWS, Azure, Google) easily.
The ecosystem factor is real. I was looking at implementing the SCIM protocol [0] in our user management app, and if we were on Spring I could have just added an Apache boot-starter dependency and been done in a few days. However my company uses the Play framework and it’s going to take me weeks to implement it by hand.
If I ever found a startup I will mandate that we use Spring Boot (java/kotlin) until we grow big enough to afford the extra overhead with other frameworks. Spring Boot is truly a Get Stuff Done framework
It would be hard to convince some people of this, because "everyone knows Spring is enterprise". Unfortunately many only have experience with legacy companies, bad code or through reading old blog articles, and base their opinions on that.
It's actually something you need to have experienced yourself to recognize the possibilities.
It may sound strange, but I enjoy going through the long list of projects in the Spring web site. I almost always find something cool and is surprised at how much they can simplify complex functionality
The learning threshold is also relatively low, because they tend to use common best practices in the framework.
I’ve spoken about this before but choosingg Play and not Spring has been my companies biggest mistake. It has lead us down so many half documented custom solutions that would have just worked out of the box if we had chosen the more popular stack.
I like Kotlin, but the lack of checked exceptions really kills it for me. Exception safety is a bigger thing for me than null safety.
The learning curve was not that hard, and I got comfortable with it.
In contrast, I find React, Next.js and other frameworks more complex, and it takes a lot longer to be comfortable