I don’t know anything about the authors and I have only read the two posts, but statements like “Every language has a complexity budget. Java blew through it with generics in Java 5.” and “First we got Generics. We all know how that went. While it’s passably better than what was originally there, it’s still not worth a damn.” make me furrow my brow. As for generics, I gladly trade in the more complicated syntax for better static typing. Annotation processors can do the same for non-null values, mutability, problems with equality and identity. They can bring linear types into the language, and make pretty much every kind of program analysis I can think of easier.

I don’t understand why there is such much animosity towards JSR 308. It is much less intrusive than generics were; unless you plan to use raw types, the updated collections libraries virtually forced you to adopt generics to a certain degree. That’s not the case at all with annotations. If you like you can easily ignore the entire idea.

Now, perhaps I’m just not a good programmer, and that’s why I prefer to ride with training wheels like generics, more precise type systems and better warnings, but this kind of humility has never hurt me so far. It does not make sense to be so frugal on the syntax side; the semantic benefits by far outweigh the costs.

I’m definitely not a fan of how generics were implemented using erasure, and I believe there are shortcomings both in the annotations provided with Java 1.5 and JSR-308 (see LAPT-javac, xajavac and blog posts), but I’m a firm believer that programmers have benefited a lot from generics, and that they will benefit in a similar way from annotations.

The beautiful thing about annotations is that dealing with them works on two different difficulty levels: Implementing annotations is not perfectly straight-forward, they use a syntax that is a bit different than the one used for regular Java classes, and that can be a bit confusing. Using annotations that have already been implemented, however, is easy; it’s an absolute piece of cake. This means that the annotations framework, especially with the annotation processors in JSR 308, can be used by more seasoned programmers to provide a lot of value even to programmers who do not know all of the details.

As a programming language researcher, I’m excited about annotations because they allow me to extend and modify the Java language in a relatively safe, convenient and compatible way. The resulting experimental languages may not be the most elegant ones, but they do the trick. Considering the two different levels of difficulty, and the possibility to completely ignore annotations, I have no idea why programmers would dislike annotations so much that they would abandon a language that can still be used exactly the same as without annotations.

My main project is about testing concurrent programs (blog category). Two of the goals are race detection and schedule-based replay for Java programs, in the specific context of unit testing. I have also created invariant checker that allows the programmer to make statements about the concurrent behavior that have to hold true. I’m in the process of annotating the Java API with those invariants, but that’s a gargantuan effort. I’d love to get some help here.

Of course, my work has spawned some side projects as well. First, I really wanted Java annotations on local variables, something that is legal according to the Java grammar, but not supported by any of the current Java compilers and JVMs, so I did my first javac hack and created LAPT-javac. Allowing the invariant checker to perform Boolean operations of existing invariants was very cumbersome with the annotations defined in the Java standard, and the problems could all be solved very simply by allowing subtyping for annotations. I therefore created my second, much more important javac (and Java API) hack, xajavac (blog category), which greatly extends the capabilities of annotations. I’m currently lobbying for it to be included in some future version of Java or a JSR.

Recently, I have worked on Mint (blog category), a multi-stage extension of Java. Multi-stage programming (MSP) provides a safe way of generating code at run-time. In mostly-functional languages like MetaOCaml, this has been used to reduce the performance penalties of abstractions such as loops, recursion or interpretation. The main advantage of MSP compared to other techniques, such as string or LISP quotations, is that MSP guarantees type safety for the generated code statically, at the time the program is compiled.

I have also dabbled with some other limitations of Java, such as the lack of tail-call optimization and the very restrictive nature of final variable initialization, but I haven’t had enough time. I’ve published a few papers on object-oriented design and CS education, and even started writing a textbook (blog category), but again, there’s not enough time for me or for my co-authors.

During the last few years, I’ve also been quite involved in the development of DrJava (blog category), a Java IDE specifically targeted at students. My work with DrJava is mostly “productive procrastination”, and I have introduced many “80%/20%” solutions: Features that work in most cases, but not all, but they greatly enhance the productivity. I believe DrJava has now become an IDE that can actually be used for large projects as well; in fact, we do all our DrJava development in DrJava. The enhancements are “80%/20%” and not “100% solutions because often we lack the infrastructure.

I’ve been a teaching assistant for many semesters, so there are some rants that go along with it. For the first time during the Fall 2008 and Spring 2009 semesters, I was an instructor and tought full courses on my own. I was thrilled, and I wrote a bit about this experience too (respecting confidentiality, of course). In the semesters since, I have supervised students doing independent studies in Computer Science. Then there’s also some fairly general stuff about grad school, of course. And there are some ramblings that are somewhat off-topic.

I hope you’ll enjoy reading my blog (although it serves mostly as a work diary for me). If you want to comment, please email me at mgrickenriceedu, and I will gladly set up an account for you.

I took the header photo in Finland, where my mother grew up as a child.

At last! I was a little bit disappointed by the original feedback I received for LAPT-javac.

All of this information, along with the binaries for the modified compiler and the API, is available on the xajavac website.

Now I should write a more formal tech report about this, I should contact Michael Ernst of the JSR 308: Annotations on Types project, and I should modify the code I wrote to for my MS thesis to take advantage of annotations with subtyping.

Subtyping for annotations is also mentioned, but to my delight only under “Out-of-scope issues”, a.k.a. suggestions. So at least in the near future, xajavac seems to be the only project to incorporate annotations with subtyping into Java.

I’ve now created a modified compiler, based on the LAPT-javac compiler I wrote a while back. The new compiler is called xajavac, for “eXtended Annotation javac”, and supports annotations on local variables, like LAPT-javac, and subtyping for annotations.

Now I can write the following:

I’m now working on providing an API that supports access to these annotations at runtime.

Well, while the latter may still happen, so far it seems like LAPT-javac and I have pretty much been ignored. There was one email with a question about how LAPT-javac relates to another project, Javari from MIT, and there was one comment in my announcement thread on Lambda the Ultimate about pluggable annotations in JSR 269.

Here’s my reply to the LtU comment:

Hi!

Thanks for your comment and for the pointer to JSR 269. I wasn’t aware of that one before, so I guess there’s yet another JSR that I need to track ;)

I looked at the Early Draft, and it looks like it supports a slightly extended annotation syntax as compared to Java 5.0 and provides a vastly improved support infrastructure that pulls apt into the standard API and extends it.

There are references to annotations on local variables, but I’m not exactly sure we can rely on that. After all, you can annotate local variables in Java 5.0, and the API provides the ElementType.LOCAL_VARIABLE enum value to control if an annotation can be applied to a local variable, yet the Java 5.0 compiler and apt completely ignore them.

Another reader also asked if I was aware of the Javari project at MIT and if what they were doing was similar to what I am doing. I have looked at Javari, and even though it’s not even the primary focus of that exciting project, they specify an extended syntax for annotations that allows you to annotate pretty much anything in a Java program. So what they are doing is way more compli cated and extensive than what I did. I just made the Java 5.0 compiler work the way I thought it should work, given the Java 5.0 language.

There was a very encouraging paragraph on the Javari website: Apparently, Sun has agreed to extend annotations (and hopefully the way they can be processed) in Java 7.0; until then, the Javari team will provide a modified javac that supports the 7.0 syntax.

That’s great, for two reasons: At least by the time Java 7.0 comes around, my hack should be unnecessary. And with Java 7.0 (and the Javari modification before that), we’ll get extended annotations. However, Java 7.0 is still very far away, and at least from what I can tell, the Javari modification is not yet available.

Until then, I’m hoping that my hack will be useful to someone (it is useful to me) and that maybe Sun will notice how easy it was to do, so perhaps it will get rolled into 6.0 already? I know those chances are slim, but one can dream… ;)

Thanks again for your comments and question. If you have any other questions or comments, please let me know, either here or by sending me an email (contact information is on the project website).

I’m looking forward to hearing from you, and I will keep everyone posted about improving (=hacking) the reflection API and apt.

I guess two other JSRs that I should keep on my watch list are JSR 202: JavaTM Class File Specification Update and JSR 305 (see Java Community News article). Especially JSR 305, lead by Bill Pugh of the FindBugs project looks interesting, relevant and challenging.