I talked to James, my office mate, today. He has been working on NexGen, a Java compiler that does generics without resorting to erasure, so types are (almost) first class. NexGen also uses a class loader, and it should eventually also be integrated into DrJava, just like my concurrent unit testing stuff. So one thing we’ll have to do is make sure that our class loaders play along well with each other and with the class loader that DrJava has.
James suggested I could use an optional class cache. Classes that have already been instrumented could just be stored somewhere. Of course, I have to make sure the cached class file is still up-to-date. That means I have to have access to the Java source file that corresponds to it (not a big problem, there’s a SourceFile attribute) and check that the Java file hasn’t been changed since the class file was instrumented. James suggested I should also do a hash over the source file.
Thanks for the suggestion! James has an account here on the blog now, so maybe he’ll read and comment every once in a while.
I should also mention that I registered the domain concutest.org for this project, by the way. I realized my hosting package included a few free domains. I’ve also excluded <clinit> from being cloned for decorators, by the way. That works now. Guess what? I have another problem now:
java.lang.VerifyError: (class: Test7, method: main signature: ([Ljava/lang/String;)V) Incompatible object argument for function call Exception in thread "main"
I haven’t figured out what that means yet.
