jdk2ikvmstarted 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:
-Yrangeposalone it not enough: it's not supposed to work after the typer phase. Details here.
jdk2ikvm(April 2011) Do-it-yourself files:
ikvmcworks (September 2010)
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
jdk2ikvmperforms 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
jdk2ikvmand 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.
scala.iomigrations, 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
-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.