Jackpot - James Gosling's Latest Project

Pete Bevin writes "Artima has a fine interview with James Gosling, creator of Java, about his latest project. It's called Jackpot, and it treats the parse tree as the program. This makes refactoring much, much more intuitive. The article has some good insights into code visualization, technical writing, and making your programs more understandable."

Comments

here it is

[CowBovNeal]

Analyze this!
A Conversation with James Gosling, Part I
by Bill Venners
Jun 9, 2003

Summary
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.

Treating Programs as Algebraic Structures
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.

Creating Visual Representations of Programs
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 o