Passionate developer in Java and Scala. And sometimes, something else. A few months per year, someone calls me "professor". CoFounder of Scala By The Lagoon @scalagoon
@siy
:
Spring being a "resource hog" may have been accurate some years ago (the Spring 2.5 app I was writing in 2008 wasn't light for sure) but I have small Boot applications in production that are really fast and relatively "small". And I'm looking at Quarkus and similar projects to make that even smaller.
It's not because Spring got better, it's because hardware significantly improved since then. Anyway, I'd highly recommend to take a look at Micronaut. It's kinda Spring done better in some aspects. It doesn't avoid Spring conceptual flaws like shifting errors to runtime and use of exceptions in business logic. But it performs a lot of things at compile time where Spring uses runtime reflection. This significantly reduces memory footprint and improves performance. In Techempower benchmark Micronaut in average about twice as fast comparing to Spring. It's still quite bad comparing to what actually Java can do though.
I'm more of a Micronaut fan instead of Quarkus but in any ways I had enough performance with Boot and WebFlux now not to switch to one of those. Reason is I need some stuff not yet written for them. I may try to do it myself but I doubt it will be soon so, if you don't need to shutdown those services and start up many times Spring is still fine
Well yeah for Monoliths never being able to shut down because of states, no replicas and such. For stateless service not too big and getting restarted frequentliy due to updates and so it's good. Different days different purposes different quality
The only thing I dislike in Spring practices is reflection which is a part of a lot of things in Java so can't say that Spring would dominate here. However, don't know what your aiming at. Restarts solve some issues that require JVM tuning (maintenance in other words) and these thing were mainly caused by reflection in cases I've seen so far. And that's what I though about when I saw maintenance. However with removing of XML I had no issues of maintaining most of the code. Maybe Advices were a bit ugly.
Spring really shines in how poorly it uses reflection. Must admit I didn't knew that it's possible to perform as poorly in this regard as Spring does. But this is another story (let me know if you're interesting). Reflection is not bad practice per se, although it is a significant obstacle for switching to more recent Java versions. Instead I mean other things. You already mentioned advices and there are other examples of using string constants as code, for example profiles. The shift of some errors from compile time to run time. Almost every Spring application has "context loads successfully" test because it's pretty common when Spring application can be compiled but can't be started. Then there is use of exceptions as part of the business logic. Then there is Spring "majic" which results to subtle, hard to nail down issues. All of the above are examples of bad (or very bad) practices which are used by Spring and encouraged to use by developers.
Under maintenance I mean not restarting app from time to time. Instead I mean adding/changing functionality as business requirements evolve over the time. Here you can meet things like breaking application just by adding (not using!) yet another Spring dependency or floating bugs caused by conflicting dependencies. It also worth to mention that long living apps often updated/maintained by different people and Spring "majic" (in particular, autowiring) makes code much harder to understand and navigate.
OK, can't argue with some of those but Autowired for me is not bad at all and I quite like to have it. Anyways as I said maintaining Spring app in most cases was quite easy for me when not using too much advices, or such. However I do use Autowire in Controllers, Services, Facades.. such to wire those same things together, but not in domain models (which I did see were made in some cases) or any other part of the code as I never had desire to do so. Once I wanted to provide quick small fix for some prototype and made Map<String,Objec> cache which made me realise what can actually happen when you have too many components and autowires for them (for those that may read this and don't get it, it will inject spring application context cache :D somehow). I guess I just didn't program in that way that I had to worry about those things. I know framework magic can be really bad but I avoid such things and never even think about them as solution.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@siy :
Spring being a "resource hog" may have been accurate some years ago (the Spring 2.5 app I was writing in 2008 wasn't light for sure) but I have small Boot applications in production that are really fast and relatively "small". And I'm looking at Quarkus and similar projects to make that even smaller.
It's not because Spring got better, it's because hardware significantly improved since then. Anyway, I'd highly recommend to take a look at Micronaut. It's kinda Spring done better in some aspects. It doesn't avoid Spring conceptual flaws like shifting errors to runtime and use of exceptions in business logic. But it performs a lot of things at compile time where Spring uses runtime reflection. This significantly reduces memory footprint and improves performance. In Techempower benchmark Micronaut in average about twice as fast comparing to Spring. It's still quite bad comparing to what actually Java can do though.
I'm more of a Micronaut fan instead of Quarkus but in any ways I had enough performance with Boot and WebFlux now not to switch to one of those. Reason is I need some stuff not yet written for them. I may try to do it myself but I doubt it will be soon so, if you don't need to shutdown those services and start up many times Spring is still fine
From my experience, Spring is quite bad in regard to application long term support and maintenance. If this is not an issue, then yes, Spring is fine.
Well yeah for Monoliths never being able to shut down because of states, no replicas and such. For stateless service not too big and getting restarted frequentliy due to updates and so it's good. Different days different purposes different quality
It's not about restarts. It's about practices promoted by Spring. So yes, if quality and long term maintenance is not an issue, then Spring is fine.
The only thing I dislike in Spring practices is reflection which is a part of a lot of things in Java so can't say that Spring would dominate here. However, don't know what your aiming at. Restarts solve some issues that require JVM tuning (maintenance in other words) and these thing were mainly caused by reflection in cases I've seen so far. And that's what I though about when I saw maintenance. However with removing of XML I had no issues of maintaining most of the code. Maybe Advices were a bit ugly.
Spring really shines in how poorly it uses reflection. Must admit I didn't knew that it's possible to perform as poorly in this regard as Spring does. But this is another story (let me know if you're interesting). Reflection is not bad practice per se, although it is a significant obstacle for switching to more recent Java versions. Instead I mean other things. You already mentioned advices and there are other examples of using string constants as code, for example profiles. The shift of some errors from compile time to run time. Almost every Spring application has "context loads successfully" test because it's pretty common when Spring application can be compiled but can't be started. Then there is use of exceptions as part of the business logic. Then there is Spring "majic" which results to subtle, hard to nail down issues. All of the above are examples of bad (or very bad) practices which are used by Spring and encouraged to use by developers.
Under maintenance I mean not restarting app from time to time. Instead I mean adding/changing functionality as business requirements evolve over the time. Here you can meet things like breaking application just by adding (not using!) yet another Spring dependency or floating bugs caused by conflicting dependencies. It also worth to mention that long living apps often updated/maintained by different people and Spring "majic" (in particular, autowiring) makes code much harder to understand and navigate.
OK, can't argue with some of those but Autowired for me is not bad at all and I quite like to have it. Anyways as I said maintaining Spring app in most cases was quite easy for me when not using too much advices, or such. However I do use Autowire in Controllers, Services, Facades.. such to wire those same things together, but not in domain models (which I did see were made in some cases) or any other part of the code as I never had desire to do so. Once I wanted to provide quick small fix for some prototype and made
Map<String,Objec> cachewhich made me realise what can actually happen when you have too many components and autowires for them (for those that may read this and don't get it, it will inject spring application context cache :D somehow). I guess I just didn't program in that way that I had to worry about those things. I know framework magic can be really bad but I avoid such things and never even think about them as solution.