Sponsored Link •
James Gosling talks with Bill Venners about his current research project, code-named Jackpot, which builds annotated parse trees for programs and can help you analyze, visualize, and refactor your program.
For the past several years, Java's creator James Gosling has been working at Sun Labs, researching ways to analyze and manipulate programs represented as annotated parse trees, a project called Jackpot. Compilers have long built parse trees when they translate source code into binary. But traditionally, programmers have worked with source code primarily by manipulating text with editors. The goal of the Jackpot project is to investigate the value of treating the parse tree as the program at development time, not just at compile time.
In this interview, which will be published in multiple installments, James Gosling talks about many aspects of programming. In this first installment, Gosling describes the ways in which Jackpot can help programmers analyze, visualize, and refactor their programs.
Bill Venners: What's the state of Jackpot, your current research project?
James Gosling: Jackpot has been really cool lately. It's what I'm spending most of my time on, and it's been a lot of fun. I was really hoping to have something I could hand out at JavaOne this year, but I've been finding too many entertaining things to do.
It's a very different world when a program is an algebraic structure rather than a bag of characters, when you can actually do algebra on programs rather than just swizzling characters around. A lot of things become possible.
Bill Venners: Like what?
James Gosling: If you look at any of the refactoring books, most of those refactoring actions become much more straightforward, in ways that are fairly deep.
Moving a method isn't just cutting and pasting text. It's a lot more than renaming the parameters and swizzling them around, because you really want to be able to do things like construct forwarding methods. When you construct forwarding methods, they're different from the original methods.
You can't just replace all uses of the forwarding method by uses of the moved method,
because they actually behave slightly differently. The difference is usually around what
happens when the pivot parameter is
null. That can lead you into a deep
morass of essentially theorem proving about properties of the code fragments that you're
moving, to understand how they behave with respect to
null. And you can
treat all kinds of code manipulation that way.
So Jackpot has a baby theorem prover, or algebraic simplifier, that knows an awful lot about data flow and the implications of values. And it really does treat your program as a piece of algebra to be simplified and transformed. It can do an awful lot of interesting analysis that pays off when you want to make fairly significant pervasive changes to very large programs. That analysis pays off, for example, when you want to replace one API with another API that is almost the same. Often "almost the same" is actually harder than "radically different." I spent most of the last four months working on this baby theorem prover, and that's been a lot of fun.