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.
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.