Local Variable Annotations

Ever since I found out that annotations on local variables are allowed but do not show up in class files nor at runtime, I was severely disappointed. To me, this is a big gap in an otherwise very interesting system. The thread checker annotations begin to look like a secondary type system that is put in place on top of Java’s primary type system, but I can’t apply it everywhere because I’m not aware if local variables are annotated. I was particularly shocked that not even apt, Sun’s annotations processing tool, can get me access to annotations on local variables.

Sun’s position that “there’s just no way we could put them in the class file” is absolutely bogus. Just make up another attribute, like the LocalVariableTable or LineNumberTable. Or… like a RuntimeInvisibleParameterAnnotation attribute, which can contain annotations for a method’s parameters. How are parameters and local variables so different? The RuntimeInvisibleParameterAnnotation attribute is basically a jagged array of arrays of annotations: The first dimension is the number of parameters of the method. The second dimension is the number of annotations on that parameter, which might be zero.

What I propose, and have already implemented as part of my concurrent unit testing class file framework, is to use the same format of the RuntimeInvisibleParameterAnnotation attribute for local variables: The first dimension is the number of the local variable, as specified in the LocalVariableTable. The second dimension again is the number of annotations on the local variable.

I have started working on a small processing tool, lapt, that parses Java files in conjunction with class files that have already been generated from them. First, I tried to do the parsing of the Java files myself, just with the debug information present in the class files, but I’ve realized that will not be enough; there would be many corner cases in which I could not accurately detect a method’s beginning, etc.

Fortunately, I’ve found a pretty accessible parser generator, ANTLR, and a rather good looking Java 1.5 grammar written by Michael Studman. I still need to look at Scott Wisniewski’s Updated Java 1.5 Grammar, which is supposed to be an improvement on Studman’s grammar.

Right now, my lapt can parse in a Java file and print out the Java source code of the annotations on the local variables. The challenge now is to insert them in the right format into the class file. In general, that is pretty easy, even though there are a few quirks in how the AST is generated, particularly when it comes to dotted class and member names.

What I’m currently unable to do is find the right fully-qualified class name for an annotations class. I’m making educated guesses if it’s used anywhere else in the class file, but that’s not enough. I’ll have to read up on the details of class resolution and provide a class path. I’d imagine it would go something like

  1. inner class of the current class
  2. inner class of any of the containing classes
  3. any class specifically imported
  4. any class on one of the imported paths (sort of imports intersected with class path)

The other idea that I had was to let javac do all of that. Instead of generating the annotations attributes myself byte by byte, I would create a temporary file with dummy methods that immediately follow the original methods, and those dummy methods would have the original method’s local variables as parameters. Parameters can be annotated, no problem. javac compiles the file, and I simply steal the annotations from the dummy methods, rename the attribute and attach them to the original method.

I think that could work quite easily actually, but it involves more text processing, something I always view as imprecise, especially since ANTLR somehow manage to lose line and column information, and it also involves a compile. So I think I’ll first take a stab at generating the annotations bytewise by doing the correct class lookup myself. It just has to be spelled out somewhere.

This is really only a small side project, an enabler for a full-blown thread checker, but I think many people could potentially love lapt, and it would show Sun that they realy did get it wrong. Hey, maybe I an even get an JSR out of this. I had hoped to finish this in a couple of days, but obviously it’s taking a little longer, but especilly on Monday, I was a code monster. 10 AM before the noon meeting, 2 PM after COMP 311, completely forgetting the COMP 617 seminar, at the office until midnight. At home, microwave meals, and more work until 4 AM. Out of bed at 8 AM, on campus at 10 PM…

On the DrJava front, I looked over Dan’s shoulder to find out what it takes to make a release. Yes, our 2nd update to the stable release is out: drjava-stable-20060918-1737 release. I also looked at a few bug reports, and there really seems to be something funny going on when we’re working across networked filesystems, not only APF, but also on our very own Windows labs, which use SAMBA, I believe.

One bug report was easy to close, misunderstanding of threading and synchronization, but another one was about memory usage. I added code to the About and Error Window dialogs now to display the used/free/total/maximum amounts of memory that the VM can give us, and in the process of testing that fixed another bug in command line handling.

When I now open the About dialog, look at how much memory is used, then open a project, close it and look at how much memory is used, it’s about the same. It seems like we have a major memory leak. However… I inserted a Runtime.gc() call to induce garbage collection before showing the memory statistics, and after a while, memory went down again. I guess I’m just not understanding what gets collected. I don’t think we have a reason to panic, though.

After doing the auto-grading for COMP 311 Project 1 by myself on Saturday morning, on Monday Dave, Felipe and I met for about an hour and a half and discussed grading. Felipe finished his third yesterday, I finished mine today. Our plan is to look over the completed reports one more time for better consistency and then send them out, on Friday at the latest.

Tired man, out. Four our of sleep last night… I’m just worried that I’ll wake up in the night again, can’t go back to sleep, start working, and then I’ll get tired when it’s time to go to campus.


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in DrJava, xajavac. Bookmark the permalink.

Leave a Reply