Vaguely! 
I’m actually halfway through writing a blog post on PraxisLIVE’s implementation of this. PraxisCORE, PraxisLIVE’s runtime, is designed from the ground up to be a live-programming / hot-swapping framework for Java, for development and runtime purposes (eg. influenced by SmallTalk, Erlang, Extempore, etc.). It rejects Java’s built-in hotswap, as well as things like JRebel or HotswapAgent/DCEVM, as not being fit for this purpose.
So, what does that mean in practice. Well, it doesn’t use agent-based hacks and works kind of in the opposite way. We load a new class each time, and the framework handles injecting state from one iteration to the next, creating or disposing of resources as necessary. By doing things this way, we can maintain state, while still allowing for adding and removing methods and functions (I emphasise both because lambdas generally don’t work with default hotswap either, which makes this far less useful with Java 8)
The Processing nodes actually work like a sketch but draw to a PGraphics, which means we can mix multiple “sketches”. One decision in doing the wrapper though was to run setup() each code iteration and reset all styles behind the scenes - PraxisLIVE tries very hard to ensure if you remove code you need, it will show up immediately, not the next time you run things - another big failing with the other hotswap options if you change your setup()!
Oh, and while not doing hacks, we use an in-memory file system and classloader to interact with the compiler API, which means source code and bytecode never hits the disk when hotswapping - 20ms sounds about right - it certainly feels instantaneous!
Sorry, long post, but you asked … 