Mainsoft: Running .NET on the JVM While Maintaining Performance

Posted by Ryan Slobojan on Jul 19, 2007

Sections

Development,

Architecture & Design

Topics

Java ,

.NET ,

Java plus .NET Integration ,

Stories & Case Studies

Tags

migration ,

Mainsoft ,

Java EE

Mainsoft recently released version 2.0 of Mainsoft for Java EE (formerly known as Visual Mainwin), and also released an intriguing whitepaper which showed that a .NET-based application which was cross-compiled to run on Java EE using Mainsoft for Java EE actually performed better in several areas than the original .NET-based application did. InfoQ spoke with Mainsoft CEO Yaacov Cohen to learn more.

First, Cohen was asked to describe how Mainsoft for Java EE worked:

The cross-compilation engine cross compiles the Microsoft Intermediate Language (MSIL) code generated by the .NET Framework compilers into Java Byte code. Our Java-based implementation of the .NET Framework runtime supports classes on which the application will execute. Finally, our Visual Studio extension enables developers to code, compile, deploy and debug Web and server applications on the Java Enterprise Edition platform.

Since the code is cross-compiled at the bytecode level, there is no source conversion - this means that Visual Studio.Net remains the sole development environment for the ported application. InfoQ also learned that Mainsoft has reimplemented a large portion of the .Net Framework in Java, including ASP.Net, ADO.Net, and the Web Services API - however, because Mainsoft for Java EE has a focus on web and server applications, components such as Windows Forms have not been implemented.

InfoQ looked at a Mainsoft whitepaper which presented a case study of one company's use of Mainsoft for Java EE to port an existing .Net-based Windows application over to a Java EE-based Linux application, and discovered the following things:

• The ported Java EE application worked on IBM WebSphere, BEA WebLogic and Apache Tomcat
• The ported Java EE application was tested on Windows, Linux, and AIX
• On identical hardware, the ported Java EE application (running on WebSphere):
  • Handled 8% more requests per second (RPS) than the original .Net application
  • Had better CPU scalability, with almost linear increases in RPS
  • Had at least 4% faster response time across all tested user loads
  • Handled at least 5% more RPS under heavy load

On why Java was faster than .NET, Cohen was careful to point out that the whitepaper intended to show that server applications could be ported without a performance penalty:

We deliver equivalent performance by tuning our open source .NET implementation to fit WebSphere's architectural strengths, similar to how Microsoft's .NET framework leverages the strengths of IIS and Windows. For the performance study, we configured the appropriate garbage collection algorithm, page size and heap size on each OS and hardware configuration tested. We also identified the need to optimize the IBM Java Virtual Machine on some scenarios that were exposed with our libraries. These changes are now widely available in the WebSphere Application Server 6.1 release.

With the number of companies that have recently open-sourced their products (such as Sun's JDK, Terracotta's DSO, and Adobe's Flex SDK), InfoQ asked Cohen if Mainsoft was going to follow suit. He replied:

Cross-platform .NET is an ambitious project, and next to Novell, Mainsoft is the largest contributor to the Mono open source project. We share all our .NET Framework assemblies with Mono, with the exception of the core library mscorlib.jar, which is Mainsoft's proprietary Java EE implementation of the .NET core class library.

Mainsoft also offers a freely available developer edition, called Grasshopper, which can be used for deployments on Tomcat and single CPU configurations.

1. Back to top

   Terracotta for .Net

   by ARI ZILKA

   Would be interesting to see if a .NET object can be shared across instances using Terracotta beneath.

   Reply

2. Back to top

   Re: Terracotta for .Net

   by Ilya Kharmatsky

   Since ".Net object" become in Mainsoft for J2EE a regular "java object" - it should not be a problem...

   Reply

• Older >