3 ms·

I've been through the whole evolution from Spring with XML configuration to the current 'convention over configuration' approach of Spring Boot. I actually lik

I've been through the whole evolution from Spring with XML configuration to the current 'convention over configuration' approach of Spring Boot. I actually liked the idea behind the XML configuration when I first got to know Spring in 2007. With this you could decouple the composition of your application from the actual code. You could deliver a jar and the user could decide with his own XML which parts to use and which not, for instance if he wanted to use your software in test mode or if he wanted to use another database. Otoh, most people who were using Spring were just following the cargo cult and not using any of the freedom that XML offered, and then all the XML configs were just massive overhead. Then came Spring annotations. For the cargo cult followers this must have been a big relief. For those of us who really used the XML application configuration, the decoupling of code and configuration was now gone. There was still the option to use XML but it was frowned upon by the community. And finally there was Spring Boot. The advantage of Spring Boot is that if you just want all the default Spring choices you can have a full fledged service up and running in no time. This looks really nice in blogs and demo's. With 'convention over configuration' you only have to adjust the parts where you don't like the defaults. This might seem nice but if you're working on a larger software project this can quickly turn into a major headache. All kind of choices are made for you by conditional spring beans which you might not even know they existed, there can be complex conditions determining their behaviour that might change all of a sudden when you add a new jar to your classpath. Spring has one big advantage though. It is so very popular and widely used that as a Java developer you only need to get good at this one framework and you will get plenty of job opportunities for years to come. And the reverse is also true for employers: just choose Spring as your framework and you will have no problem finding new developers.

jillesvangurp 6y ago
There's a next stage after annotations. The current thinking is to replace annotations with function calls. It makes more sense if you use Kotlin because Java is a bit verbose when you do this and in Kotlin you get to create nice DSLs. This cuts down on use of reflection and AOP magic that spring relies on and also enables native compilation. It also makes it easier to debug and it makes it much easier to understand what is going on at the price of surprisingly little verbosity. Kofu and Jafu are basically still experimental but work quite nicely https://github.com/spring-projects-experimental/spring-fu/tree/master/kofu https://github.com/spring-projects-experimental/spring-fu/tr... Another trend is native compilation. Spring native just went into beta (uses the Graal compiler). That still relies on reflection but they re-engineered the internals to be more native friendly. Spring Boot basically added the notion of autoconfiguring libraries that simply by being on the classpath self configure in a sane way. It's one of those things that makes the experience a bit more ruby on rails like. Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid). Compared to XML configuration, Spring has come a long way. Separating code and configuration is still a good idea with Spring but indeed not strictly enforced. @Configuration classes can take the place of XML and if you use the bean dsl, that's basically the equivalent of using XML. Only it's type checked at compile time and a bit more readable.
- lmm 6y ago
  > Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid). You can't though, because the usual pattern is that the classpath-based self-configurer imports a non-public class that contains all the actual configuration. So you can't customize or extend the autoconfigured version - you have to either accept it as is or replicate the entirety of it from scratch.
  - jillesvangurp 6y ago
    You can disable configuration classes and then set things up manually. I did this recently with the mongo driver.
    - lmm 6y ago
      Right, but you can't customise the automatic config. It's all or nothing - you have to either use the whole autoconfig as-is or reimplement everything that it does yourself.
Cthulhu_ 6y ago
While nowadays I wouldn't touch Spring with a ten foot pole if I had the choice, back then (must have been mid 2000's as well), Spring helped me really develop as a software engineer; everything I know now from (Java-style) interfaces, contracts and unit testing comes from that one six month internship where I was left to my own devices to build an application similar to what Sonar is nowadays (or was a few years ago). I still have the code somewhere, so many comments <_<.
algo_trader 6y ago
Errr, so today would you for Spring or Spring Boot ? For a large ebay-sort-of backend with lots of REST apis to both front end and back end itegrations?
- rsj_hn 6y ago
  I would choose it. Bottom line, organizing and maintaining large codebases on which lots of developers are collaborating is going to be painful no matter what your stack is. There is no technical fix for overcoming all the dependency and coordination problems created by large, complex software. As nothing is going to remove that cost from you, the best you can do it transform one of set painpoints into a different set of painpoints. The most dangerous choice is then the one where the painpoints are not well understood, even to the point where you think they aren't there. Trust me - they are there, lurking - waiting for you to start tripping over them. At least with Spring there is a well understood approach with a large pool of developers and some accumulated wisdom. That's better than most alternatives for real world use. OTOH, if you are building a small project with a small team, it doesn't matter too much which framework you use, just use whatever your team members are most comfortable with. If your intention is to grow into a massive project, then finding devs who have experience in your stack will matter more down the road.
abledon 6y ago
One power of Spring Boot , non-xml based code is using an IDE like intelliJ for refactoring/navigation. XML is hard to refactor/navigate if you're dealing with 1000s of files.
- lmm 6y ago
  You don't need Spring Boot for that. You can use plain Spring with annotation-based config, no XML needed. And your IDE navigation will work, whereas with Spring Boot it frequently finds the wrong bean definition because of all the dynamic magic (ConditionalOnClasspath, ConditionalOnMissingBean etc.).
michaelcampbell 6y ago
My thoughts exactly. I started with the XML flavor, and although I hate XML, it was (IMO) a far superior mechanism than annotations. All the config was in one spot. You didn't need to recompile to change it. So much easier, all in all.
krooj 6y ago
Looks like I came up the same path as you: XML in Spring 2, with Spring 3 adding lots of support for annotations. Once Spring 4 came around, I was... okay with abandoning _most_ XML, but some things just made way more sense in XML, such as Spring Security configuration. I first saw Spring Boot demoed by Josh Long at a Pivotal office in Toronto, and my first reaction was to wretch at autoconfiguration, since it was extremely apparent where it would lead. The team I was working with at the time were a hard NO on annotation-driven config, which I thought was extreme at the time; however, several jobs later, I saw the proliferation of Boot and the autoconfiguration cancer it caused. Some projects were explicitly re-written with a hard technical requirement to not use Spring Boot, and those code bases ended up cleaner and more readable as a result. The current gig is steeped in Boot and I've just given up and instead tried to use TypeScript for anything new, simply to avoid the Spring ecosystem. What's more terrifying is watching new grads and green developers use this magic trash and have zero concept of what's actually happening under the covers. When I say zero concept, I really do mean that they have no idea what the servlet spec is, let alone containers or reverse-proxies.
bcrosby95 6y ago
I guess it depends upon what you mean. For many projects, DI frameworks are a giant cargo cult. Whether you use annotations or XML. More broadly, Java's obsession with "flexibility" (really, false flexibility) is a giant cargo cult. If you're talking about webapps specifically... using XML in Java was not a cargo cult. It was the only option in 2007. Even if you didn't use Spring.

jillesvangurp 6y ago

There's a next stage after annotations. The current thinking is to replace annotations with function calls. It makes more sense if you use Kotlin because Java is a bit verbose when you do this and in Kotlin you get to create nice DSLs. This cuts down on use of reflection and AOP magic that spring relies on and also enables native compilation. It also makes it easier to debug and it makes it much easier to understand what is going on at the price of surprisingly little verbosity. Kofu and Jafu are basically still experimental but work quite nicely https://github.com/spring-projects-experimental/spring-fu/tree/master/kofu https://github.com/spring-projects-experimental/spring-fu/tr... Another trend is native compilation. Spring native just went into beta (uses the Graal compiler). That still relies on reflection but they re-engineered the internals to be more native friendly. Spring Boot basically added the notion of autoconfiguring libraries that simply by being on the classpath self configure in a sane way. It's one of those things that makes the experience a bit more ruby on rails like. Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid). Compared to XML configuration, Spring has come a long way. Separating code and configuration is still a good idea with Spring but indeed not strictly enforced. @Configuration classes can take the place of XML and if you use the bean dsl, that's basically the equivalent of using XML. Only it's type checked at compile time and a bit more readable.

lmm 6y ago
> Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid). You can't though, because the usual pattern is that the classpath-based self-configurer imports a non-public class that contains all the actual configuration. So you can't customize or extend the autoconfigured version - you have to either accept it as is or replicate the entirety of it from scratch.
- jillesvangurp 6y ago
  You can disable configuration classes and then set things up manually. I did this recently with the mongo driver.
  - lmm 6y ago
    Right, but you can't customise the automatic config. It's all or nothing - you have to either use the whole autoconfig as-is or reimplement everything that it does yourself.

Cthulhu_ 6y ago

While nowadays I wouldn't touch Spring with a ten foot pole if I had the choice, back then (must have been mid 2000's as well), Spring helped me really develop as a software engineer; everything I know now from (Java-style) interfaces, contracts and unit testing comes from that one six month internship where I was left to my own devices to build an application similar to what Sonar is nowadays (or was a few years ago). I still have the code somewhere, so many comments <_<.

algo_trader 6y ago

Errr, so today would you for Spring or Spring Boot ? For a large ebay-sort-of backend with lots of REST apis to both front end and back end itegrations?

rsj_hn 6y ago
I would choose it. Bottom line, organizing and maintaining large codebases on which lots of developers are collaborating is going to be painful no matter what your stack is. There is no technical fix for overcoming all the dependency and coordination problems created by large, complex software. As nothing is going to remove that cost from you, the best you can do it transform one of set painpoints into a different set of painpoints. The most dangerous choice is then the one where the painpoints are not well understood, even to the point where you think they aren't there. Trust me - they are there, lurking - waiting for you to start tripping over them. At least with Spring there is a well understood approach with a large pool of developers and some accumulated wisdom. That's better than most alternatives for real world use. OTOH, if you are building a small project with a small team, it doesn't matter too much which framework you use, just use whatever your team members are most comfortable with. If your intention is to grow into a massive project, then finding devs who have experience in your stack will matter more down the road.

abledon 6y ago

One power of Spring Boot , non-xml based code is using an IDE like intelliJ for refactoring/navigation. XML is hard to refactor/navigate if you're dealing with 1000s of files.

lmm 6y ago
You don't need Spring Boot for that. You can use plain Spring with annotation-based config, no XML needed. And your IDE navigation will work, whereas with Spring Boot it frequently finds the wrong bean definition because of all the dynamic magic (ConditionalOnClasspath, ConditionalOnMissingBean etc.).

michaelcampbell 6y ago

My thoughts exactly. I started with the XML flavor, and although I hate XML, it was (IMO) a far superior mechanism than annotations. All the config was in one spot. You didn't need to recompile to change it. So much easier, all in all.

krooj 6y ago

Looks like I came up the same path as you: XML in Spring 2, with Spring 3 adding lots of support for annotations. Once Spring 4 came around, I was... okay with abandoning _most_ XML, but some things just made way more sense in XML, such as Spring Security configuration. I first saw Spring Boot demoed by Josh Long at a Pivotal office in Toronto, and my first reaction was to wretch at autoconfiguration, since it was extremely apparent where it would lead. The team I was working with at the time were a hard NO on annotation-driven config, which I thought was extreme at the time; however, several jobs later, I saw the proliferation of Boot and the autoconfiguration cancer it caused. Some projects were explicitly re-written with a hard technical requirement to not use Spring Boot, and those code bases ended up cleaner and more readable as a result. The current gig is steeped in Boot and I've just given up and instead tried to use TypeScript for anything new, simply to avoid the Spring ecosystem. What's more terrifying is watching new grads and green developers use this magic trash and have zero concept of what's actually happening under the covers. When I say zero concept, I really do mean that they have no idea what the servlet spec is, let alone containers or reverse-proxies.

bcrosby95 6y ago

I guess it depends upon what you mean. For many projects, DI frameworks are a giant cargo cult. Whether you use annotations or XML. More broadly, Java's obsession with "flexibility" (really, false flexibility) is a giant cargo cult. If you're talking about webapps specifically... using XML in Java was not a cargo cult. It was the only option in 2007. Even if you didn't use Spring.