At least for java, you can spin out a new class loader which intercepts all class loading tasks and basically shim the dynamic module from the permanent runtime platform very trivially. For unloading, you'll likely need conventions on how to shut it down cleanly to not leave a ton of garbage around. Want a new version? Spin up a new class loader, rinse and repeat. If you need stateful between versions, you clearly need to mindfully build a facade for that outside of the dynamic parts. This is all not hard, but not introductory either. That said, I basically wrote similar DLL loaders in my first year writing c so many decades ago, so shrugs.

Class loading from a DLL is one thing, persisting the state and reloading that state on-top is another. In Java, you can use the class loader to load new instances of a class, but it's up to you to transfer state before giving that class over to your program again. In C# it's a similar story with System.Runtime.CompilerServices. The trivial bits are the fact that you can use reflection to do this rather easily in both Java and C#. In C++ isn't not as simple. The struct/data signature may change, you need a temporary storage vessel (old object?) to copy to the new class object. While it's still "digital plumbing", it's not that easy to do and then hot-reload the whole stack.