RuntimeSearch is a project designed to make debugging easier for developers. It is based on a paper entitled “RuntimeSearch: Ctrl+F for a Running Program” from the ACM Automated Software Engineering Conference. Our goal is to allow users to search for strings, objects, and variables during the runtime of their program. This is especially useful for times when a simple “ctrl+f” wouldn’t work since strings and attributes of objects may not appear directly in source code. For example, concatenating “hello” and “world” in order to produce “helloworld” could be identified with RuntimeSearch, but not by simply using “ctrl+f” and searching for “helloworld.” We chose to implement RuntimeSearch as a plugin in the IntelliJ IDE for Java development, although RuntimeSearch is not inherently language or IDE specific.

In order to implement RuntimeSearch in the IntelliJ IDE, we needed to add extended capability to both Java's built-in debugger and the user's program in which the search would take place. The two main, separate processes are the debugger with extended capabiliy and the user's program with extended capability. We refer to the debugger with extended capabiliy as the plugin side of RuntimeSearch (the icon), and we refer to the user's program with extended capability as the agent side of RuntimeSearch (the secretive-looking agent dressed in black). We also had to the plugin and the agent to communicate. In order to get the agent side of RuntimeSearch to work, we needed to inject code into the compiled (.class) versions of the user's program. This is done with something called a Java agent. We used the ASM library in order to transform classes in order to make them act the way in which we wanted. In particular, we made class files check to see if any strings are equal to the string a user is searching for when it is put into memory. The way in which manipulation works is depdendent upon the way Java bytecode operations work. We inserted certain operations in Java bytecode into the class files. These operations were: duplicating the string currently on the operand stack, putting the class name, file name, and line number of the place in the user's code in which the string was loaded into memory, and calling our comparison method and popping off what we just put onto the operand stack and using them as arguments for this method call. On the plugin side, we had to work on the user interface of the plugin and have it execute the user's code when our RuntimeSearch icon was clicked with the Java agent (which does the instrumenting) as a command-line argument in this execution. Once clicked, a window pops up where the user can enter the string for which they want to search and the type of search that they want to do. As of now, we have only implemented regular search, regex search, and fuzzy matching search. We hope to have object search and variable search working in the future. Due to the fact that the plugin side and the agent side are different processes, we needed to find a way for them to communicate. We decided to use RMI, or Remote Method Invocation. We had the agent side start a server and the plugin side start a client that connects to the server and grabs a special object called the "RMI Object." The client could then perform method calls on this object. It is through these method calls that were able to pass data between the two processes. The plugin side calls a method on the RMI Object to send the agent side the string and the search type, the agent updates the RMI Object with information about matches found (the package path and line number), and when the plugin side grabs this object, it uses it to show the user where new matches were found. Ultimately, there were three main sections of work when it came to implementing RuntimeSearch: the plugin side, the agent side, and the communication between the two.