Sponsored Link •
Bill Venners: I read that Jackpot can create interesting graphical representations of a program. What is that about?
James Gosling: Jackpot can take this underlying algebraic structure— it's really the annotated parse tree—and generate a visual representation from that. Our internal notion of the truth is not text. But once it's not text, all of a sudden you can display it in really interesting ways.
We've got an underlying rule engine that's able to do structural pattern matching very efficiently. We can go from the structural patterns it sees in your code to visual representations. So you can write what is kind of like a reverse grammar, where you associate structural patterns with what you can think of almost as TeX descriptions of how to represent the patterns graphically. What you see on the screen has been generated from this pattern matching. So we can, on a user chosen basis, turn various program structures into all kinds of visual representations.
You can, for example, turn the square root function into the obvious mathematical notation. You can turn the identifier theta into the Greek letter theta. You can turn division into the horizontal bar with numbers stacked. And we've done experiments with wackier things, such as trying to generate real time flow charts. That's kind of goofy, but entertaining. Other things like hiding block contents, doing interesting typography, doing typography on comments, all actually work out reasonably well.
Bill Venners: At previous JavaOnes, I have seen some visualization tools that I thought were useful. One of them analyzed your code and drew diagrams that showed the coupling between packages. I felt those diagrams could help you realize that you've got a lot of coupling going from one package to another, which you may not realize by looking at individual source files. Visualization tools like that can help, I think, but a lot of tools that draw graphical representations from source don't seem to help much. Let's say you analyze a big program and generate inheritance charts, with thousands of boxes and lines going all over the place. That often looks as confusing as the source code does.
James Gosling: Yes, doing that kind of visualization is a real challenge.
James Gosling: We've got a bunch of hooks in Jackpot for plugging in analysis modules. We want not only to be able to do analysis, but to be able to act on that analysis. We have some pieces that do pretty interesting things.
For example, often it's considered bad form to have public instance variables. One piece of analysis, therefore, is to find all the public instance variables. But we can find them and also make them private, add all the setters and getters, and account for what it means to actually access the variables via setters and getters. We can also do things like find all methods whose natural home is not the class they are actually in.
Bill Venners: How do you detect that?
James Gosling: If you look at the analysis books, there are various ways of detecting that. For instance, if you've got a static method that takes an object as a parameter, and it modifies that object, then somebody probably just slapped that method in there because it was easy. They were editing that file, so they put the method there. But they really should have put it someplace else. We've got something that will find those methods and actually move them, then change all the uses of that method to do the right thing. So we're trying to couple analysis with action.