Hi, I've got an idea for a Summer of Code project and I'd really appreciate some feedback on it. If people generally find it interesting, I'll go into more detail. GSoC: Haskell JVM bytecode library ================================== What ---- I'm thinking of writing a library for analyzing/generating/manipulating JVM bytecode. To be clear, this library would allow one to load and work with JVM classfiles; it wouldn't be a compiler, interpretor or a GHC backend. Motivation ---------- Over the past 20 or so years, the JVM has become a very popular platform. It's used in industry, on the web, and on mobile devices. The main programming language used is Java, but recently, quite a few new ones have turned up (including some functional ones): Scala, Clojure, Jython, Rhino, etc. All the languages compile to a single, universal, and very well documented format, namely classfiles. The problem with classfiles is that they're blackboxes. Once written, they can't be modified and they can only be read by the JVM. It's quite a shame, really, since we could do all sorts of interesting things with them. Possible uses ------------- If we had a well-documented and reliable way of working with classfiles, we could: * perform static analysis to identify bottle-necks, common errors, etc. * do further optimization pases over the binary; maybe, we could optimize for size more aggressively (UPX does this for win32 exes, why shouldn't it be done for classfiles?) * generate interfaces for the libraries directly from the binaries * visualize the structure of complex programs * modify existing programs to route-around errors * generate JVM code directly from Haskell programs * etc. This project aims to provide exactly this -- an easy way of working with JVM bytecode. Previous work ------------- Quite a few similar projects have existed in the past, most of them are mentioned on this page: http://www.haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NE... None of them have tried exactly this (some were more ambitious, some never bothered with providing a library), and most of them are undocumented and unmaintained. References ---------- JVM Spec: http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html Cheers, Alex