Java platform with its classloader hierarchy and security manager provides the perfect environment to run third-party applications in a secure, isolated environment, e.g., javaws or former JBoss. When debugging such runtime, developers are very often forced to run third-party binary blob to reproduce the error. At that moment, decompilers and disassemblers come to play to see what the blob is actually doing. If an issue is found more likely in blob than in the runtime, then it is necessary to prove a fix. That forces developers of runtime to change the blob and use a new version in runtime. In addition, such binary blobs are very often hard to decompile and are very often incomplete. So the work has to move from filesystem into running JVM. This approach, when automated, may open new areas of testing based on automated runtime patching of JVM.

Java offers interesting approaches to obtain bytecode of currently running classes. By using easy tricks, this runtime bytecode can be decompiled (done in previous thesis).

This thesis aims to enable composition of an in-memory dependence tree and compile a freshly decompiled class back to a running JVM (Java Virtual Machine). The freshly decompiled class fragments are very likely not to be able to compile out of the box, and the student will have to elaborate on their structure. This issue may not be solvable on Java language level, and bytecode operations or java-assembly operations may be necessary to be used. Even if the class bytes are adapted and its decompiled source modified and compiled, the replacement of classes in a running JVM has its limitations. The student need to investigate possible solutions and propose the best approach.