There's actually two kinds of patching, and the type referred to here is the older and uglier one.
Back in the Cretaceous Period I worked on IBM mainframes as an OS-level programmer. We did some original work, but a lot of what we did was install and configure vendor packages - both IBM's own OS and other products and some third-party products. Those mainframes had less overall power than an Apple Watch, so building a major system could indeed take several hours. But since bugs were no less common back then and you can't just "turn a mainframe off and on again" every time something goes sour, we needed a way to update the products we had installed. Rather than have IBM rebuild the entire OS every time something needed tweaking, we'd use a program called "ZAP" to alter the loadable code (equivalent to a class). Often the patch that we'd ZAP in would be a jump to a spare area of memory, do what it needed, and then go back to where it came from. Frequent offenders even had a pre-reserved area of memory to patch into.
It's not that bad when everyone's doing assembly language and the instruction set is tidy enough that you can assemble/disassemble code in your head. It gets much uglier when working with high-level languages, and uglier still when optimizing compilers are used and the generated code no longer linearly follows the source code.
The other kind of patching is still done, primarily on Unix-like systems. The Unix "patch" program takes the "diff" output of two text files and applies them as a series of text edits (using "sed" or the like). This isn't so much a bug-fix strategy as it is something that distro package builders do to tweak source code to make it more inline with the quirks of that particular distro, allowing a common source code for all distros. It has also been used to ship trial changes from one developer to another.
But, as I said, the patching in question is of the first kind, not the second, and I cannot recommend it either. The Java world is just not set up for that.