SourceGear Uses Mainsoft for Java EE to Create Eclipse Plug-In for Vault

Eric Sink, Software Craftsman, SourceGear describes how he used Mainsoft for Java EE (aka Grasshopper), to expedite the creation of an Eclipse plug-in for Vault, SourceGear’s popular source control tool, and Fortress, an Application Lifecycle Management (ALM) solution for small and medium-sized development teams.

The tale of a technology decision

I really want an Eclipse plug-in for Vault and Fortress. For several months I have been trying to figure out the best way to get one.

Our product are and will remain largely focused on the Visual Studio user, but more and more people are asking us to let them use Vault and Fortress from within Eclipse. Developing a Vault client for Eclipse would allow us to connect with a lot of developers that we currently cannot reach, on multiple platforms.

However, we have a portability problem. Our products are Windows-centric and built on C#.

Defining the boundaries of the problem

We fully expected that we have to rewrite the UI code for our Eclipse client. But it would be really nice if we didn't have to maintain two copies of our core client library, VaultClientOperationsLib, or "OpsLib" for short. It is the library upon which all of our client applications are built. In principle, this 48,000 lines of code should be reasonably portable. It does a lot of file I/O, some threading and some networking. Nothing here really needs to be platform-specific.

The first thing we did was to consider and reject three possibilities that we deem to be unattractive:

• Rewrite OpsLib in something more portable.
  If this library had been written in C++, then all of the cross-platform issues would be more straightforward. Tedious, but straightforward. But we're simply not willing to do this. Rewriting OpsLib would require a lot of effort and risk, while providing no value for our current user base, all of whom are happy using the product on Windows.
• Port OpsLib to Java and maintain two copies of it.
  We could probably port OpsLib to Java in a month or two. But we're not willing to do this either. Maintaining two copies of this library would be far, far too tedious. Every time we make a change to the C# version we would have to go make the same change to the Java version.
• Find a way to call C# from Java.
  In a nutshell, the idea is here is to use Mono to execute our C# code and create a bunch of glue code that would make the OpsLib API available to Java. It should be possible for all of the glue code to be automatically generated, although it might take a little time to work out the kinks. This idea is not ideal, however, because it's not "pure Java". Users will need to install the Mono runtime, which is large and must be separately compiled for each operating system. Ideally, we would rather just have a collection of jar files.

How about a translator?

The first thing to observe is that C# and Java are remarkably similar. The syntax isn't all that different, and the runtime libraries have many similarities. Wouldn't it be cool if we had a translator that would take our C# source and generate Java source that "Just Worked"?

I started by exploring ANTLR, a very cool parser generator that can output C# code. But along the way I realized that mcs (the C# compiler from the Mono project), would make a much better starting point. I simply need to make it generate Java source code out the backend instead of IL (the Intermediate Language used by the .NET runtime).

So I started hacking. I spent two days adding a new backend for mcs, and I realized that while eventually we could make this work, it could take a long time. Beyond the syntax conversion challenges, the Java code converted from C# was still trying to call the .NET Framework, but those libraries didn’t exist in the JVM.

Enter Mainsoft

In the end, we decided to purchase a solution to this problem from a company called Mainsoft. Their product—Mainsoft for Java EE—happens to do exactly what we want. (I have no affiliation with this company other than the fact that SourceGear is their customer.)

Mainsoft's tool is a Visual Studio add-on which compiles C# to Java byte code instead of to IL. They include a class library that provides support for .NET Framework stuff.

I was ultra-skeptical, but in practice, this tool is working surprisingly well. We had to make very few changes to the OpsLib code, all fairly minor, and the port took about three weeks. The resulting Java version of OpsLib passes our suite of regression tests, and that speaks volumes about the quality of work Mainsoft has done. Those tests are truly sadistic.

In the end, we've got a pure Java solution, nothing but a collection of jar files. We can run them on Windows or on Linux.

By purchasing Mainsoft's product, we allow ourselves to keep our primary focus on four core product development. That's a big win. Since June 2007, SourceGear offers full support for Visual Studio and Eclipse clients on Windows, Mac OS X, and Linux.

Got a case study of your own or comments on this story? Discuss it in our Forum!