SourceGear Uses Mainsoft for Java EE to Create Eclipse Plug-In for
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
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
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.
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
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,
Got a case study of your own or comments on this story? Discuss it in our