re: ...as long as you don't follow their particular flavor of best practice, yes, decently so.

As long as you don't use Spring. Real Java best practices are perfectly fine.

Spring Boot is quite fast, thank you. Does a ton of work for me, I can pick and choose my favourite server/serialization library/application metric source/templating engine/whatever, and it's still fast, and doesn't need that much of configuration because most defaults work just right.

Spring is a resource hog and is extremely slow. Just take a look at Techempower benchmark. Note that fastest Spring results in this benchmark - Spring Flux, which is not exactly the same thing which usually meant under "Spring".

And for the record, I was not referring to anything but core Java in terms of performance hits from "best practices". Unless all the courses, guides, and tutorials I've encountered over the years have not been using "best practice", but then I have grievances with the official documentation. I listed several of these bad habits in another comment, won't waste everyone's time repeating it here.

(P.S. "Best practice" is a mythological beast in any language. "Good practice" exists, but it requires application of thought, discernment, and tailoring to the situation.)

Unfortunately most courses, guides and books are teaching not best practices. In most cases they are repeating the same bad habits that you're don't like. Fortunately really used practices are much better (although far from ideal).

That's fair. Sounds like someone needs to write a book on how to do Java well.

Hum, possible project for me in another few years?

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

code of conduct - report abuse