Category Archives: eclipse

APT

As I mentioned in my last post I’ve been playing around with database interfaces. While doing this, I’ve discovered something new: APT, the annotation processing tool for Java. I’ve known for a while that it existed but only now have I discovered what the big deal is. APT. Kicks. Ass!

In the database interface for Java I’m working on, you specify the structure of a database through annotated interfaces, essentially the same way things work in DLINQ. For instance, a database called test containing two tables would be specified like this:

public @Database("test") interface ITestDatabase extends IDatabase {
public @Table IDataSet public @Table IDataSet orders();
}

Using this interface you can open a connection to an actual relational database and fetch the contents either directly (by calling the persons or orders method) or you can specify more complex queries through something more “magical” which I’ll describe later.

The thing is that there’s a lot of ways you can get these interfaces wrong. For instance, you must use interfaces, not classes. Database interfaces must extends IDatabase. The methods that correspond to tables must return a IDataSet of some sort. And so on.

I considered this to be a problem until I discovered the annotation processor framework. An annotation processor is essentially a compiler plugin that is given access to parts of the syntax tree during compilation. That can be used for all sorts of interesting things, including issuing errors and warnings. So I’ve created an annotation processor that you can plug into your compiler and then it will check that all database-related interfaces are well-formed, and it works beautifully.

To top it all off, the compiler in eclipse now supports APT. If you just configure it correctly, which is no more difficult than using an external library, you get custom checking right in eclipse:

Of course, as with all power tools, you have show a little restraint and not issue all sorts of lame warnings just because you can…

…even if it it’s so easy the code almost writes itself:

for (MethodDeclaration method : decl.getMethods()) {
if (method.getSimpleName().equals("foo")) {
env.getMessager().printError(method.getPosition(),
"Enought with the 'foo' methods already!");
}
]

I know this tool has been around for a while. Why has it taken me so long to discover how useful it is — has there been some kind of hype that I’ve missed?

And yes, I know I’ve misspelled “enough”.

Character pairs

Finally! My mac is back. I haven’t made much progress with saturn since my last post but in the meantime I’ve been working on something else: a contribution to eclipse.

When you create a text editor in eclipse, you can specify a character pair matcher that is typically used for highlighting matching parentheses and brackets.

In many cases when eclipse defines an interface, it also provides a default implementation that you can customize and use in your own plugin without having to deal with the full complexity of implementing the interface from scratch. In the case of ICharacterPairMatcher, however, there is no such default implementation. A few months ago I filed a feature request in the eclipse bug system for such a default implementation that you could give a set of which charaters to match, for instance "()", "[]" and "{}" and then this implementation would do all the work.

…yada yada yada, my implementation of such a character pair matcher, DefaultCharacterPairMatcher, is now a part of eclipse, as well as a new implementation of the matcher used in the Java editor. So, barring some unforeseen incident, from the next release of eclipse, my code will spring into action whenever you type a parenthesis, brace or bracket in the Java editor or any other editors that use the default character pair matcher. I think that’s pretty cool.

Saturn UI

Sigh. My mac is still being repaired. Fortunately, it turns out that my access code still works at the university so even though it’s not exactly ideal, it gives me a place to work when I really want to. So I have made some progress over the last few weeks.

Threading now works (see) but the scheduler is exceedingly stupid. One nice thing about this implementation, though, is that threading is completely deterministic. Interrupts appear to be nondeterministic but are actually based on values returned by a random number generator. All you need to know to repeat an execution is the seed of the generator and then the run will be exactly the same. That’s been pretty useful.

I’ve also found time to work on an eclipse plugin. Now there’s a perspective with a saturn editor with syntax coloring and integrated launching:


Notice the little saturn perspective marker in the top right corner. It took me forever to draw that.

The compiler is integrated with the IDE so there’s immediate compilation when files are saved:


Finally, there’s a simple debugger:


There’s still a lot of work left to do before the IDE is decent but I think it’s already surprisingly useful. You get a lot of functionality with relatively little work if you ask eclipse nicely.

By the way, if you look closely at the code in the screenshots you’ll notice that I’ve changed the block syntax from fun (...) -> ... to fn (...) -> .... I don’t really care if it’s fun or fn but I remember caring once, a few years ago when I first saw ML and O’Caml, and I remember preferring fn. I thought my former self should have some influence on this language. Even though he probably wouldn’t have liked it; he thought object orientation was for wimps. Good thing I’m running things now and not him.

Disappointed!

I’m working on our new neptune plugin for eclipse and I draw a lot of inspiration from the JDT java plugin that comes with eclipse. One thing I really like is that you can do refactorings and navigation in a file even if parts of the source is not legal java code. The parser they use apparently just skips the illegal parts and gets right back on track as soon as the source becomes parseable again. For instance, the parser has no problem reading this nonsense:

public class Klass {

int float double foo
String bar() {
List baz() { { {
float %$%$ quux();
try catch finally if else
class K {

}

This class is shown in the outline as having one field, foo, three methods, bar, baz and quux, and an inner class K. I would have expected the unmatched brackets or illegal characters to throw the parser off a bit but it doesn’t seem to care.

My first guess was that maybe they used the indentation as a guide but apparently whitespace is completely irrelevant — putting the whole thing on one line makes no difference. So to understand how they did it I ended up single-stepping through the gory innards of JDT until I found the parser and hoped to see all sorts of well-documented heuristic rules that I could understand and use in our own plugin.

Full of anticipation, I stepped over lines and lines of initialization code, saw the first token being read from the input and finally reached the sacred inner loop of the parser. After having gone around in the loop a few times I noticed that what appeared to control everything was the result of a single method call. Ready for the big revelation, I stepped into the method and found a single line:

return term_action[term_check[base_action[state]+sym] 
== sym ? base_action[state] + sym : base_action[state]]

Disappointed! I hate automaton-based parsers.

Checked exceptions

For a long time, I have been really annoyed with checked exceptions in Java. They break encapsulation and seem to pop up all over the place especially when I’m really busy and irritable. And because I have to handle these exceptions right there in the middle of my code where I don’t want to, my exception handlers are often accompanied by angry all-caps comments about how much I hate checked exceptions.

I’m not the only one though; they decided to not have them in C# (see this interview with Anders Hejlsberg) and mr. Thinking in Java, Bruce Eckel, has an essay about why they’re bad.

I decided to suggets that we change the severity of uncaught checked exceptions in eclipse from ‘error’ to ‘ignore’ at work. Unfortunately, it turned out that there was no such option in eclipse, I don’t know why I thought that. Instead, I made a feature request for it in the eclipse bug system (#119230). It only took them a few hours for them to reply: it shouldn’t be possible to configure the eclipse Java compiler so that it accepts code that is illegal by the java language specification. Dammit, that sounds pretty reasonable.

Well, now I’ve filed a feature request at sun’s developer network () but I’m not very optimistic. We’ll see what happens.