Hot patching a jar is not a scalable solution in the long term, especially if you're considering that in a larger project there may be multiple unmaintained projects that now need permanent hotpatching.
This isn't only about companies, people who develop open source software on their own are just as affected by log4j. Funding and resourcing can at least help people and maybe incentive handing the project to someone else.
At least with gradle you can easily add some logic to the buildscript to substitute all instances of a specific dependency for a java library/application with a fork.
It's only a handful of lines of code and it is technically a bit hacky but it's really no worse than any of the other jank you are forced to do when building any moderate to complex gradle based java project.
And when another library is unmaintained and breaks, you add those few lines again. And again and again and again, until your gradle file is 90% hotpatching your dependencies.
Yep but that's just the breaks. Especially with ecosystems that have tall dependency trees.
Luckily those few lines can mostly be shared and you end up with a handful of lines and a map from old dep to new dep which makes it not too painful.
This whole issue is why I don't like these ecosystems but at the very least in the Java space dealing with this issue isn't too painful. I can't speak for the JS space but this is also a pretty trivial fix in the Rust space and it isn't too painful with C++ or C projects. Nix (mostly used for Haskell but it's a pretty solid universal package manager) has some pretty good tooling for modifying upstream dependencies. Spack (package manager specialised for HPC and embedded projects) has really good support for this as well.
My point being that people have run into these issues in the past a lot in certain spaces and as a result those spaces have come up with solutions for this problem a long time ago. It just so happens that for the most part the average dev doesn't see a lot of that because these issues get dealt with upstream or just aren't common in most industries. The embedded industry is particularly used to this considering how much of the kit from manufacturers is just outright wrong or broken 3 levels deep. The only reason I'm as well versed with this as I am is because I've been in the embedded space patching over broken HALs and I've bled my blood dealing with legacy enterprise applications that were initially written in Java 1.1 and haphazardly dragged along over the decades.
TLDR: This is an ugly fix but ultimately it's the best ugly fix to an ugly problem and every software ecosystem eventually gets to deal with it once they get old and crusty enough.
