I remember the first time I used a Java decompiler… I picked a random class file, fed it to the decompiler and sat in amazement as the tool spit out Java code that was almost identical in all parts to my original source code. Ever since I saw that, I have always wondered how hard it could be to create a tool that would output something else than Java… Would it be possible to have a program that could translate Java into pretty much anything?

It turns out that it’s quite possible.

For the past couple of years, I and a few other people have been working at just that. The idea is to provide an API that makes it easy to read bytecode in a form that’s relatively structured (identifiying method and class names, iteration structures, etc…) so that developers can easily generate source code for whatever language they feel like.

I’m very happy to announce an initial release of project Toledo.

Toledo is a very ambitious project that’s made of three parts:

  • An API that reads class files and expose it as higher constructs in order to make code generation as easy as possibe.
  • A set of modules built on this API that generate code in several languages (see below for the languages we support today).
  • Extra libraries in these languages to bridge the gap between JDK libraries and target libraries.

This last point was the one that caused me the most worries. I wasn’t interested in creating a tool that generates source code which is useless because it no longer has access to the Java libraries it was built upon. Several people on the Toledo team have come up with very innovative ideas to make this port not only possible but extremely easy as well, and thanks to them, the code that’s being translated is actually really running in the target environment (see the demo section on the project home page).

I’m not going to dive deep into details with this post, but I will certainly do so in the next few months in this blog. Before I point you to the project’s page, I’d like to thank some of the people without whom Toledo would never have happened:

  • Ruby: Rick Astels, Dan Bentley

  • Javascript: Jeff Parks

  • C: Rich Austern, Laurent Desnogues

  • Python: Mike Oswell

  • Intercal (seriously!): Austin Conway

  • Lisp: Chad Older

There are a lot more languages being worked on…

For more details, go to the Project Toledo’s home page and please send your feedback!