Getting rid of compiling? Sounds crazy!
Here's how it works. Let's start with Android: You build and install your app with whatever build system you like, it doesn't matter. Now instead of launching the app directly, JIPR provides you a special launch command. This command will install an instrumentation APK, and launches your app with special classloaders and dependencies. In particular these class laoders will add instrumentation to classes at runtime, which will allow you to override its implementation.
That's half the story, and tools like Instant Run or JRebel already do this. What JIPR does differently, is that the overridden implementation is interpreted. That is, when you make a change to the your code, you uploade the Java file as-is to the app, and the app will start interpreting the new java code instead of the compiled byte code.
What about performance? It doesn't matter. At any point of time, we're only interpretting a couple of different Java files that you have changed. All other code is running from bytecode. You'll not notice this performance hit. Freeing yourself from compilation will easily pay for this.
Does this work on the JVM? Yes! The JVM doesn't provide a notion of instrumentation APK, so you might have to change the launch commands or build steps depending on the app. By the way, the best example of a long running JVM app that can take advantage of this is IntelliJ! Imagine writing plugins and having them reload into the IDE instantaneously. At the same time, you can compile the plugins and ship it to your coworkers and they'll still get the high performance version.
But Kotlin? We don't support Kotlin yet. But we think it's easy to build an interpreter for a specific language. The interpreter is just a front-end to all the heavy-work we do under the hood. For now though, we're focussing on Java.
What if method signature/name changes? Any callers of the old method will result in runtime errors. Any callers of the new method will have to be interpreted code, because otherwise the app wouldn't have compiled in the first place. The interpreted caller code will correctly call the new method.