Timely post for me. My employer has decided to “standardize on Copilot” (after previously telling us to use Gemini but never getting us the wherewithal to actually utilize the corporate Gemini license they’d established; don’t ask me to make it make sense) and it’s possible they’ll soon start requiring us to use Copilot. I expressed to a coworker that "maybe there’s something that’s technically under the “Copilot” brand that is much less invasive and bullshit that we can use so we can say we’re “using Copilot” in a “malicious compliance” kind of way but not actually have to… you know, use an LLM for anything that’s going to fuck up our regular work. Like, maybe I can use the Copilot Outlook integration to send myself emails that I can somewhat plausibly claim to be reminders to myself. Following the letter, but not the spirit, of the “law”. Maybe I can even automate it. Whatever the case, if I was to do such a thing, this graphic could be a useful resource. Though for now, we haven’t yet gotten any mandate to “use Copilot.”

We did something similar years ago. We were told we “had to use Spring” for a Java project we were building from scratch. So we used a tiny little piece of the Spring ecosystem of libraries. The Spring context, mostly. And some of the facilities that would scan for @Configuration classes. (Though we limited the packages it scanned pretty strictly.) Just so we could say “see, we used Spring”. But we used nothing but that. Most notably, we didn’t use Spring controllers or the DispatcherServlet. And even the parts of Spring that we did use, we only let certain portions of our codebase depend on Spring at all, just to limit how much contact our code even had with Spring.

Being mandated to use Spring is stupid. But Spring at least is great.

Honestly, hard disagree. It makes building a skeleton application really quick, but it’s so magical. As the guy who people come to when they’ve been banging their head against a problem (because we bumped the version on one random serialization library and now the org.springframework.core.initializer.GenericSecurityPolicyContextFactoryConfigurationProviderServiceScannerImpl doesn’t work, so we’re faced with days more of Jar hell) for days, I’d much rather we just use Servlets directly without involving Spring at all. (And god help us if we ever attempt to upgrade our Java version.)

Servlets was supposed to make everything easier. It 100% has its warts. (Servlet containers are pretty heavy. JSPs are terrible in every way. One of the things I hate most about it is that there’s no way to render a JSP to a string (for instance, for rendering email bodies) short of making a request back to a dummy endpoint on the same application that only does rendering.) But it’s comparatively very clean and explicit, avoids 100 layers of magic, keeps your list of dependencies small, it’s very obvious how you’d do any particular thing with it, etc.

But people decided it wasn’t good enough and built Spring on top of Servlets to supposedly make things easier. I have to imagine it was built by the sort of people who would “fix” their cracked foundation by adding a new story to their house. If anything isn’t acting right with Spring, you have to understand both Spring and Servlets to be able to fix it. And as I’ve probably mentioned a few times, Spring is suuuuuuper magical. And integrating other third-party things with Spring involves voodoo every time.

And then everything was good! Just kidding. Everybody agreed that wasn’t good enough either. So did they fix Spring? No. They built another story on top of the failing foundation. Spring Boot. Which adds still more layers of magic on top. I’m no fan of XML, but I’d rather deal with a web.xml file than try to figure out what the hell any particular Spring annotation is actually doing (because it isn’t working) any day.

Aside from that, you look for fixes online, and you get a Stack Overflow post with 8 completely different answers and just have to hope one is right. So I’ve learned not to even search for answers on places like Stack Overflow. Typically, I’ll go straight to the Spring source code when people come to me with issues – because they know I’m the only one brave enough to embark on such a spelunking mission. Spring isn’t really intended to be understood. It’s meant for people to throw… let’s say spaghetti… at the wall until something happens to stick.

Bah! You got me on a rant. Lol. I’m not really familiar with any other Java frameworks. But last time I worked in Django, I loved it. It’s not magic and it is intended to be understood deeply. (Hell. I’ve written ORMs in Java inspired by Django’s ORM because it was so understandable and elegant.)

Anyway. In short, my experience with Spring has been exactly the opposite of yours, apparently. I think the context is one of the more innocuous parts of Spring, and I don’t think it’s that much of a concession to use that.

Maybe I hate Spring because I’m the person that people come to when it’s broken, so every time I have to think about it, it’s because there’s some headache that it’s causing. But then again, maybe everyone else on my team would hate Spring too if they didn’t have me to externalize all the issues it causes onto. Lol.