Runtime Code Injection

The trend towards continuous experimentation enables companies and especially Web-based companies testing new functionality (e.g., new features) on a small fraction of the user base first. Based on data collected on a small subset of users in the production environment, companies decide whether new functionality can be rolled out to larger user groups (e.g., increase from 1% to 10% of the users) or whether some further changes are required, for example in case of technical problems such as bugs or if the feature does not scale (e.g., memory utilization).

A common way of implementing these experiments is by using feature toggles, which are simple conditional statements in the source code deciding which code block to execute next (e.g., whether a feature is enabled or disabled for a certain user). However, managing these feature toggles is a daunting task. Toggles must be removed when experiments finish and maintenance gets more complex. 

Example for a simple feature toggle:

if(isEnabled('fastSearch', user)) {
 // code block containing new feature
} else {
 // code block containing old functionality
}

The goal of this master project is to look at approaches which allows the developer to conduct experiments without dealing with such experimentation logic on his/her own (i.e., feature toggles). Assume the developer is working on a new feature in the IDE (e.g., IntelliJ, Eclipse) and he or she wants to conduct an experiment. The IDE should support extracting the actual changes, adding experimentation logic automatically (i.e., which users should see this new functionality), and inject the changes into the running application.

The advantages of this approach are twofold: first, the handling of experimentation logic is done automatically, releasing the developer of the burden of dealing with feature toggles. Second, by just taking the actual change and injecting the change into the running application, no recompilation and no redeployment of the whole application happens, which is a huge time saver. This allows us to give the developer immediate feedback about a new feature (or just fragments of it) within the IDE while still working on it. The idea is again that the change is released only to a small subset of the users to keep the number of affected users small in case of problems.

There are multiple approaches for example in the Java ecosystem on how to change the behavior of a running application and injecting code. This ranges from AOP (aspect-oriented programming) Tools (e.g., AspectJ), over tools such as Byteman or ASM, to concepts such as HotSwapping in which entire Java Classes are replaced at runtime.

The main tasks for this project are:

• Get familiar with the various approaches for injecting code into a running application
• Look at how changes can be extracted from the source code
• Classify those changes as for example not all changes might be suitable for conducting an experiment
• Inject selected changes into running applications using one of the approaches
• IDE plugin: Give the developer the opportunity to run experiments on changes and visualize the outcome of the experiments (e.g., by presenting some metrics).

Posted: 26.10.2017

Slide: Master Project Market Slide (PDF, 132 KB)

Further Information: Gerald Schermann