Another effective technique is to explain your code to someone else ... you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.The idea being that telling someone about the bug produces a solution by itself.
I am going to follow this advice and use this post as a sounding board to help me fix a bug in Vajra (it's not really a bug, but more of how to address an implementation issue):
Strings are to be handled specially by the JVM. There is to be only a single instance of each unique string, i.e., even if there is more than one String object that 'stores' the value "Hello, world", all these objects will share a single instance of "Hello, world" maintained internally by the JVM.
I am handling this requirement currently by trapping the execution of the ldc and ldc_w instructions (those of them dealing with string literals, that is) and either creating string objects by myself (or reusing already-created string objects, as the case may be). I am also executing the <init> method for the newly created strings manually.
Now the problem is, how to handle string objects that are created by other means, i.e. when a String doesn't come into existence through an ldc/ldc_w, but through a normal call such as
String s = new String();Should I trap these <init> calls and handle them in a special manner? But in that case, how to handle cases where one <init> method in turn calls another <init> method of String? There is also the problem of how to keep the member data of a String object in synch with the internal object representation in Vajra in this situation.
Nope, still waiting for the Eureka moment.
