jdk2ikvm: A source-level conversion tool to migrate Scala programs from JDK to .NET

`jdk2ikvm`: A source-level conversion tool to migrate Scala programs from JDK to .NET

Companion websites:

Description

jdk2ikvm started as a tool used during the initial bootstrapping of Scala on .NET, but can be used to migrate any JDK-based Scala application for which source code is available (subject to API coverage by IKVM itself). After conversion by jdk2ikvm, the resulting sources can be compiled with Scala.NET. Graphically:

Using `jdk2ikvm`

Conversion recipe
How to build and run
Why -Yrangepos alone it not enough: it's not supposed to work after the typer phase. Details here.

Case studies

A preview of Scala.NET: Cross-platform development the Scala way (May 2011)
Bootstrapping Scala.NET via jdk2ikvm (April 2011) Do-it-yourself files: patches1.zip, patches2.zip

Under the hood

Finding the source code fragment that corresponds to a given AST-level type-reference (January 2011)
A source-level, automatic API migration that preserves layout (a story of range positions) (January 2011)
How ikvmc works (September 2010)

Project ideas for `jdk2ikvm`

Targeting both JDK and .NET from a single codebase :
We have developed a tool (jdk2ikvm) to automate the migration of Scala sources from JDK to .NET (once migrated, those sources can be compiled by Scala.NET against the IKVM library to obtain .NET assemblies). Our experience with this tool is based on porting the Scala compiler itself and the Scala library. However, the API migration that jdk2ikvm performs is general in nature, and thus it would be interesting to field-test it with other large Scala applications (for a non-exhaustive list, see a Scala Corpus). "Field testing" means more than just running jdk2ikvm and hoping for the best, it includes for example running the (migrated) test suite of the application on .NET. An expected by-product of these case studies are additional conversion rules, gathered for JDK APIs previously not addressed by the conversion.

Project ideas for other source-level converters, applying the same techniques of `jdk2ikvm`

Upgrading to use a new API via source-to-source conversion:
Both source and target APIs may run the same VM. Most of the time, programmers only reluctantly modify programs to use new APIs. If at all, "library wrapping" is used (the "old" API is replaced by a facade that invokes functionality in the "new" API). AST-aware source-to-source conversion can be used to bring software up-to-date more easily. Different projects have different APIs to renovate, but usual suspects include XML APIs, JDO to JPA, or language consolidation efforts (java.io to scala.io migrations, or dumping Java 1.5 Collections in favor of Scala Collections). Summing up, this project aims at encoding the know-how that currently goes into ``Migration Guides'' (e.g., Eclipse 3.x to 4.0, JavaEE, etc.) Resources: Ralf Lämmel has analyzed API migration strategies for Java in Swing to SWT and Back: Patterns for API Migration by Wrapping and Study of an API migration for two XML APIs

Enabling a whole-program compilation mode:
This time, the compilation run receives the standard library along with the main program (thanks -sourcepath), and the conversion plugin adds as many "sealed" and "final" keywords as it can. The resulting source files are later compiled with the (unmodified) compiler, which now can apply inlining more aggressively. Details of this idea in a discussion at scala-internals.

Last updated: 2011-04-24, Miguel Garcia