Iteration 3

• Phase: Elaboration
• Dates: - February 10, 2007

Tasks to be Completed

Simple Plug-In and LIME compiled using IKVM

• As an alternative to the messaging system explored in Iteration 2, an "in-process" system of communicating between Java and .NET will be explored. IKVM (the meaning of the acronym is unclear) will be used as the system for cross-platform integration.

Assessment

Summary

The integration of Eclipse with LANDIS classes using IKVM was completed. A simple plugin with a validated time step was implemented and Victor demonstrated it.

Although less complex than the previous messaging arrangement, there are some significant deficiencies when using IKVM to integrate Eclipse and LANDIS-II. First, an additional LANDIS class will need to be written that provides a "bridge" between a LANDIS extension and Eclipse, if the former contains generics of undefined type . Second, and most significantly, there is a very large performance penalty in that it took ~30 seconds for a simple LIME RCP with a single small plugin to start. Third, IKVM does not support AWT or SWING (GUI libraries) and therefore will not be compatible with Eclipse plugins that use these libraries. A few Eclipse-based applications were tested under IKVM: although Eclipse IDE seems to work fine, eclipseTrader (stock market analyzer) has a limited functionality working with bugs and throwing SWT, XML and WEB-related exceptions, and UDig (GIS map editor) does not start at all.

However, despite these short-comings, the IKVM approach is still superior to the previous messaging system. It is relatively less complicated and easier to deploy.

Hit and Misses

• Generally speaking, the iteration itself was a huge hit because all tasks were completed allowing us to fully evaluate the IKVM integration method.

Lessons Learned

• IKVM is easy to download and installation only requires file copying. However, in order to be compatible with .NET 2.0 a couple configuration files are needed, which are not provided on the web site.
• IKVM has very poor documentation and is still a "work in progress".
• IKVM can operate in dynamic mode (converting .jar and .class files on the fly) or static mode (converting .jar files to .dll files). Only the dynamic mode is suitable for LIME because of the flexible plugin architecture, but it requires 20-30 seconds for converting bytecodes from .jar files into MSIL when LIME starts.
• IKVM does not support empty-type generics (e.g., InputValue(T)). Therefore, it does not allow us to use existing LANDIS classes in Java. Instead, a "bridge" .dll must be created that does not contain empty generics.
• Steps a Developer Would Need to Take:
  1. Create a "bridge" .dll - not terribly complicated and could be a very cookie-cutter operation.
  2. Generate a stub file from the "bridge" .dll using ikvmstub.exe utility. The generated stub file is in .jar format and can be referenced from Java classes.
  3. Create a plugin for the LANDIS extension. This is an automated process that is assisted by an Eclipse wizard.
  4. Import the generated stub file into the plugin.
  5. Create View.java - this is the GUI for an extension with windows, lists, buttons, etc. Implement calls to the imported stub file to validate input values.
  6. Export the plugin with View.java to a directory. Again, this is a very automated task.
  7. Copy the directory into the appropriate LIME plugins folder. Also, copy the "bridge" .dll file into the main LIME folder.