5 ms·

This is REALLY old. Spring is completely different. Yes it has it's problems but Spring Boot is still an excellent framework that has no serious rival in breadt

This is REALLY old. Spring is completely different. Yes it has it's problems but Spring Boot is still an excellent framework that has no serious rival in breadth/depth/ease of use balance. It doesn't use XML anymore (although it can) it's all annotations. You can code to it with Kotlin if you don't like Java and can do some pretty cool things there. Java 17 has records and many other cool things that make the code very terse. Also Spring Boot isn't a "Framework for a Framework" as the article claims. It's a convention based package of the applicable tools. That simplifies a lot of the development process and makes everything far more accessible. The basic Spring Boot stuff is super simple. However, I will agree there's a LOT of complexity under the hood. That's a feature, not a bug. You need depth if you want to build something that scales in the enterprise and Spring does scale well. I don't like DI very much. I would prefer a more direct framework with imperative programming which IMO fits better with Java. But all of them don't have the traction and breadth of Spring Boot which is why I use that. So I'm pretty happy with it.

konradb 5y ago
Micronaut or Quarkus seem like good competitors, does Spring Boot have the edge over them?
- krzyk 5y ago
  Quarkus had a really annoying static only DB layer which turned me off. Spring Data was way better with the interfaces. I don't know if Quarkus changes recently (well, in 2-3 years) in that regard. And 3 years ago it didn't support newer JDK versions, it supported up to JDK 11 AFAIR, while there was already JDK 13 or something like that. It was a bummer for a framework that advertised as hipster-new. AFAIK they migrated out of jboss library that was holding them back in newer JDK support but I was burned twice already and didn't want to give another try.
  - jxi 5y ago
    It has to be static or AOT compatible to compile to native with Graal.
  - invalidname 5y ago
    I really like a lot of the ideas in Quarkus. They also pushed for Spring Native which is an interesting new direction. But to me one of the biggest values is sheer traction. Spring controls the market completely. You have so many engineers with deep real world experience with Spring. So many books, blogs etc. When you run into a problem there's someone. When you need to hire, it's easy. That's a huge benefit.
- StevePerkins 5y ago
  The only things those frameworks offered were compile-time dependency injection (Spring injects at runtime, and can make startup slower)... and support for building AOT native executables with GraalVM (Spring couldn't do that before because Graal has poor support for its reflection-based dependency injection). Within a few months of Micronaut and Quarkus emerging, Spring started working on the "Spring Boot Native" project. Allowing you to build AOT compiled native executables with GraalVM. That’s now fully released for production if you want it. Ironically, aside from perhaps some "serverless" applications where startup time is more important, the traditional JIT applications typically outperform AOT native executables. Especially in the kind of long-running server tasks that Java is mostly used for in the enterprise. This is mostly about marketing and appearances, because newbies see the eye-popping AOT startup times (for "Hello World" demo apps), and Spring has to keep up with those bullshit examples. But the point is that Spring DOES keep up. The Java enterprise ecosystem is at a point where occasionally something new gets introduced, but then Spring adds support for the same thing within a year or two. Since "a year or two" is a snap of the fingers in the enterprise world, there's just little incentive to migrate just because a new thing is "cooler" on Reddit. Especially when the new things have a minuscule fraction of the community, working out the bugs and producing the blog posts and StackOverflow answers that you rely on.
  - sixbrx 5y ago
    Apparantly with the enterprise version of GraalVM which enables PGO, there's no longer any significant performance penalty, with GraalVM running at 97% of regular JVM throughput: https://www.infoq.com/articles/native-java-graalvm/ https://www.infoq.com/articles/native-java-graalvm/ (section "Peak performance On Par with JVM")
    - StevePerkins 5y ago
      The point is that most newbies don't understand the ramifications of JIT and AOT. And assume that AOT is dramatically BETTER performing, based on overhyped startup time benchmarks. You try to explain to people that once an application has been running for 30 seconds (or whatever), AOT will never be as good as JIT let alone better. And half the time, you just draw blank stares like the "But this goes up to eleven!" scene from "Spinal Tap". Java (and to a somewhat lesser extent .NET) exist in a totally different social bubble. Because most of the students and early stage startup workers on Reddit and HN simply don't know what they're talking about most of the time.
- jillesvangurp 5y ago
  Quarkus just moves the problem IMHO. I find it similarly convoluted to use as normal Spring. I had to deal with that a few months ago on a project. Honestly, it actually feels a lot like spring used to be; and not in a good way. Lots of annotation magic all over the place. I use Spring Boot by default. But I aggressively limit the use of annotation magic. I've never liked the byte code hacks people do to make annotations inject magical behavior. Hard to debug and painful when it does not work as expected. I don't think either of these frameworks have an edge over each other. You end up using a lot of the same underlying library ecosystem. I do like the annotation less direction that Spring has been taking since they started adding Kotlin support 4-5 years ago. If you want to, you can get rid of most annotations for things like dependency injection, defining controllers, transactions etc. Especially with Kotlin, this makes a lot of sense. With Java, dealing with builders is just a lot more painful without kotlin's DSL support. You basically end up with a lot of verbosity, method chaining, etc. But it's possible if you want to. It's a big reason, I prefer using Kotlin with Spring Boot. Makes the whole thing feel like a modern framework. The hard part with Spring Boot is being able to tell apart all the legacy and backwards compatible stuff from the actual current and proper way of doing things. There's a project that they've been pushing to get rid of all annotations: https://github.com/spring-projects-experimental/spring-fu/tree/main/kofu https://github.com/spring-projects-experimental/spring-fu/tr.... I suspect a lot of that stuff might be part of spring boot 3.x later this year. And quite a bit of it is actually already part of the current version of Spring. This makes spring boot very similar to what you'd do with ktor. All you do is call kotlin functions. No annotations. No reflection. No magic. Very little verbosity. It's all declarative. And a nice side effect is also that it makes things like spring-native easier, which they started supporting recently. It's very similar to using ktor with koin (for dependency injection). That combination is worth a try if you are looking for something lightweight and easy to use. Spring Boot has more features and complexity but it can be as simple to use as that if you know what you are doing. Mostly, keeping things simple is a good thing with Spring. Also, I don't tend to do everything the spring way. Spring integration is a bit of a double edged sword for example. It offers a subset of the features of the libraries that it integrates. If you want the full feature set, you end up working around that. IMHO, you should do that by default. I've removed spring integration from several projects.
- karmakaze 5y ago
  My biggest beefs with Spring is its use of Hibernate being a solution for late 90's EJB apps not well suited for shorter transaction scopes used today. Sadly most Quarkus references seem to use Hibernate as default. Micronaut seems to be showing more choices, but then still Hibernate comes up more than others. Leaving Spring/Boot and keeping Hibernate isn't much of a change other than perhaps some possibly efficiency (e.g. startup time or infrastructure cost).
Tarq0n 5y ago
> You need depth if you want to build something that scales in the enterprise This feels like "Mongodb is webscale". What specifically does Spring do better than its competitors?
- invalidname 5y ago
  Spring works with everything and scales horizontally really well. It can play with every framework and has many engineers/knowledge around it. Specially it has builtin caching, transaction management, DB access etc. But it connects to many external services for all of those seamlessly. It abstracts all the layers so you can easily replace everything under the hood with full compatibility as your business grows.
  - davedx 5y ago
    > caching, transaction management, DB access etc Aren't these mostly features of your data layer e.g. Hibernate? > It abstracts all the layers so you can easily replace everything under the hood with full compatibility as your business grows. Java is a perfectly capable language for implementing abstractions. What does Spring offer you there that you can't do with plain old Java?
    - invalidname 5y ago
      Yes it uses Hibernate. The integration through Spring Data is seamless. Also caching isn't just L2 Hibernate cache. It's external caching layer, integrations with Redis/memcached etc. It provides encapsulation for all of these elements that you don't have to do on your own.
    - rad_gruchalski 5y ago
      > Java is a perfectly capable language for implementing abstractions. What does Spring offer you there that you can't do with plain old Java? A concise framework where all components talk the same language across the full stack.
      - 5y ago
henk53 5y ago
> that has no serious rival in breadth/depth/ease of use balance. What about Jakarta EE?
- invalidname 5y ago
  The entire standard including all the dozen vendors shipping products occupy about 10-20% of the market based on our stats. Spring dominates the market. It's been around longer than Jakarta and influenced it a lot. Since that's made of multiple implementations there are advantages and disadvantages involved. Don't get me wrong. I like Jakarta, Quarkus et al. They bring a lot to the table and the cross pollination with Spring (which goes both ways) is great. But if you want to hire someone the chance of them having real world experience with Spring is much bigger than them having similar experience with Jakarta EE. If they have Java EE experience it isn't as applicable.
  - henk53 5y ago
    > It's been around longer than Jakarta Not really, Jakarta came from Java EE, which came from J2EE, which was released early 2000. Spring is from 2003 and started essentially as a framework for J2EE. > and influenced it a lot. It goes both ways. Spring for instance started calling code "configuration" and wanted us to put it in huge amounts of XML. Java EE started with using annotations for bean definition and injection. Spring was initially against this idea, arguing configuration should be external and not embedded in the code. Citing that you would otherwise needed to recompile your code in order to change configuration. Many years later Spring projects barely use those huge XML files anymore and its all autowire.
    - invalidname 5y ago
      Not really. J2EE has been around for a while. But it was RADICALLY different and was pretty much horrible. Then it copied many of the AOP aspects of Spring (inject etc) as it evolved. The current standard of Jakarta looks more like Spring than its original form. As such most of the implementations of the standard are much newer. So yes, the standard origins are old but that's not a relevant metric. I said, cross pollination. E.g. just recently the Spring Native example is totally an example of Spring copying a great idea from the Quarkus et al.

konradb 5y ago

Micronaut or Quarkus seem like good competitors, does Spring Boot have the edge over them?

krzyk 5y ago
Quarkus had a really annoying static only DB layer which turned me off. Spring Data was way better with the interfaces. I don't know if Quarkus changes recently (well, in 2-3 years) in that regard. And 3 years ago it didn't support newer JDK versions, it supported up to JDK 11 AFAIR, while there was already JDK 13 or something like that. It was a bummer for a framework that advertised as hipster-new. AFAIK they migrated out of jboss library that was holding them back in newer JDK support but I was burned twice already and didn't want to give another try.
- jxi 5y ago
  It has to be static or AOT compatible to compile to native with Graal.
- invalidname 5y ago
  I really like a lot of the ideas in Quarkus. They also pushed for Spring Native which is an interesting new direction. But to me one of the biggest values is sheer traction. Spring controls the market completely. You have so many engineers with deep real world experience with Spring. So many books, blogs etc. When you run into a problem there's someone. When you need to hire, it's easy. That's a huge benefit.
StevePerkins 5y ago
The only things those frameworks offered were compile-time dependency injection (Spring injects at runtime, and can make startup slower)... and support for building AOT native executables with GraalVM (Spring couldn't do that before because Graal has poor support for its reflection-based dependency injection). Within a few months of Micronaut and Quarkus emerging, Spring started working on the "Spring Boot Native" project. Allowing you to build AOT compiled native executables with GraalVM. That’s now fully released for production if you want it. Ironically, aside from perhaps some "serverless" applications where startup time is more important, the traditional JIT applications typically outperform AOT native executables. Especially in the kind of long-running server tasks that Java is mostly used for in the enterprise. This is mostly about marketing and appearances, because newbies see the eye-popping AOT startup times (for "Hello World" demo apps), and Spring has to keep up with those bullshit examples. But the point is that Spring DOES keep up. The Java enterprise ecosystem is at a point where occasionally something new gets introduced, but then Spring adds support for the same thing within a year or two. Since "a year or two" is a snap of the fingers in the enterprise world, there's just little incentive to migrate just because a new thing is "cooler" on Reddit. Especially when the new things have a minuscule fraction of the community, working out the bugs and producing the blog posts and StackOverflow answers that you rely on.
- sixbrx 5y ago
  Apparantly with the enterprise version of GraalVM which enables PGO, there's no longer any significant performance penalty, with GraalVM running at 97% of regular JVM throughput: https://www.infoq.com/articles/native-java-graalvm/ https://www.infoq.com/articles/native-java-graalvm/ (section "Peak performance On Par with JVM")
  - StevePerkins 5y ago
    The point is that most newbies don't understand the ramifications of JIT and AOT. And assume that AOT is dramatically BETTER performing, based on overhyped startup time benchmarks. You try to explain to people that once an application has been running for 30 seconds (or whatever), AOT will never be as good as JIT let alone better. And half the time, you just draw blank stares like the "But this goes up to eleven!" scene from "Spinal Tap". Java (and to a somewhat lesser extent .NET) exist in a totally different social bubble. Because most of the students and early stage startup workers on Reddit and HN simply don't know what they're talking about most of the time.
jillesvangurp 5y ago
Quarkus just moves the problem IMHO. I find it similarly convoluted to use as normal Spring. I had to deal with that a few months ago on a project. Honestly, it actually feels a lot like spring used to be; and not in a good way. Lots of annotation magic all over the place. I use Spring Boot by default. But I aggressively limit the use of annotation magic. I've never liked the byte code hacks people do to make annotations inject magical behavior. Hard to debug and painful when it does not work as expected. I don't think either of these frameworks have an edge over each other. You end up using a lot of the same underlying library ecosystem. I do like the annotation less direction that Spring has been taking since they started adding Kotlin support 4-5 years ago. If you want to, you can get rid of most annotations for things like dependency injection, defining controllers, transactions etc. Especially with Kotlin, this makes a lot of sense. With Java, dealing with builders is just a lot more painful without kotlin's DSL support. You basically end up with a lot of verbosity, method chaining, etc. But it's possible if you want to. It's a big reason, I prefer using Kotlin with Spring Boot. Makes the whole thing feel like a modern framework. The hard part with Spring Boot is being able to tell apart all the legacy and backwards compatible stuff from the actual current and proper way of doing things. There's a project that they've been pushing to get rid of all annotations: https://github.com/spring-projects-experimental/spring-fu/tree/main/kofu https://github.com/spring-projects-experimental/spring-fu/tr.... I suspect a lot of that stuff might be part of spring boot 3.x later this year. And quite a bit of it is actually already part of the current version of Spring. This makes spring boot very similar to what you'd do with ktor. All you do is call kotlin functions. No annotations. No reflection. No magic. Very little verbosity. It's all declarative. And a nice side effect is also that it makes things like spring-native easier, which they started supporting recently. It's very similar to using ktor with koin (for dependency injection). That combination is worth a try if you are looking for something lightweight and easy to use. Spring Boot has more features and complexity but it can be as simple to use as that if you know what you are doing. Mostly, keeping things simple is a good thing with Spring. Also, I don't tend to do everything the spring way. Spring integration is a bit of a double edged sword for example. It offers a subset of the features of the libraries that it integrates. If you want the full feature set, you end up working around that. IMHO, you should do that by default. I've removed spring integration from several projects.
karmakaze 5y ago
My biggest beefs with Spring is its use of Hibernate being a solution for late 90's EJB apps not well suited for shorter transaction scopes used today. Sadly most Quarkus references seem to use Hibernate as default. Micronaut seems to be showing more choices, but then still Hibernate comes up more than others. Leaving Spring/Boot and keeping Hibernate isn't much of a change other than perhaps some possibly efficiency (e.g. startup time or infrastructure cost).

Tarq0n 5y ago

> You need depth if you want to build something that scales in the enterprise This feels like "Mongodb is webscale". What specifically does Spring do better than its competitors?

invalidname 5y ago
Spring works with everything and scales horizontally really well. It can play with every framework and has many engineers/knowledge around it. Specially it has builtin caching, transaction management, DB access etc. But it connects to many external services for all of those seamlessly. It abstracts all the layers so you can easily replace everything under the hood with full compatibility as your business grows.
- davedx 5y ago
  > caching, transaction management, DB access etc Aren't these mostly features of your data layer e.g. Hibernate? > It abstracts all the layers so you can easily replace everything under the hood with full compatibility as your business grows. Java is a perfectly capable language for implementing abstractions. What does Spring offer you there that you can't do with plain old Java?
  - invalidname 5y ago
    Yes it uses Hibernate. The integration through Spring Data is seamless. Also caching isn't just L2 Hibernate cache. It's external caching layer, integrations with Redis/memcached etc. It provides encapsulation for all of these elements that you don't have to do on your own.
  - rad_gruchalski 5y ago
    > Java is a perfectly capable language for implementing abstractions. What does Spring offer you there that you can't do with plain old Java? A concise framework where all components talk the same language across the full stack.
    - 5y ago

henk53 5y ago

> that has no serious rival in breadth/depth/ease of use balance. What about Jakarta EE?

invalidname 5y ago
The entire standard including all the dozen vendors shipping products occupy about 10-20% of the market based on our stats. Spring dominates the market. It's been around longer than Jakarta and influenced it a lot. Since that's made of multiple implementations there are advantages and disadvantages involved. Don't get me wrong. I like Jakarta, Quarkus et al. They bring a lot to the table and the cross pollination with Spring (which goes both ways) is great. But if you want to hire someone the chance of them having real world experience with Spring is much bigger than them having similar experience with Jakarta EE. If they have Java EE experience it isn't as applicable.
- henk53 5y ago
  > It's been around longer than Jakarta Not really, Jakarta came from Java EE, which came from J2EE, which was released early 2000. Spring is from 2003 and started essentially as a framework for J2EE. > and influenced it a lot. It goes both ways. Spring for instance started calling code "configuration" and wanted us to put it in huge amounts of XML. Java EE started with using annotations for bean definition and injection. Spring was initially against this idea, arguing configuration should be external and not embedded in the code. Citing that you would otherwise needed to recompile your code in order to change configuration. Many years later Spring projects barely use those huge XML files anymore and its all autowire.
  - invalidname 5y ago
    Not really. J2EE has been around for a while. But it was RADICALLY different and was pretty much horrible. Then it copied many of the AOP aspects of Spring (inject etc) as it evolved. The current standard of Jakarta looks more like Spring than its original form. As such most of the implementations of the standard are much newer. So yes, the standard origins are old but that's not a relevant metric. I said, cross pollination. E.g. just recently the Spring Native example is totally an example of Spring copying a great idea from the Quarkus et al.