iNet neatly transforms .Net code into J2EE

At first blush, a product that converts .Net code to J2EE may seem a little strange. However, there are at least two business scenarios for which iNet's ability to convert to J2EE makes a lot of sense.

The most obvious one highlights the cost savings and performance improvements to be gained by deploying converted J2EE applications on enterprise-level Unix servers, midrange systems, or mainframes rather than on large clusters of Wintel servers. The net savings on hardware alone (server consolidation and scalability) would be substantial, as one or two high-powered J2EE machines can easily carry the load of many Wintel machines. Using Unix servers not only reduces server footprint requirements in the datacenter, it lowers overall server costs. Using high-powered machines to execute converted J2EE code should also yield improvements in response time and throughput, as many high-powered servers support dynamically adding resources as Web site loads change.

A second, slightly less obvious reason for converting .Net applications to J2EE is security. Suppose you had a critical Web site running on .Net. If you created a mirror of that site using J2EE, you'd provide greater scalability day-to-day. More importantly, if a security attack occurred that affected only .Net-based sites, or only J2EE sites, you could turn off whichever technology was under security risk and remain online using the alternate technology to drive the site.

With these scenarios in mind, Stryon iNet turned out to be a solid solution in my tests, converting .Net applications to J2EE by translating MSIL (Microsoft Intermediate Language) into J2EE code. Stryon also supplies Java-based run-time class libraries that are compatible with the .Net class libraries; the converted code references those libraries.

I converted several Visual Basic .Net and C# applications and Web sites, and all of them ran without a hitch. For some sites, I used Stryon's IL2Java Visual Studio .Net plug-in. For others I used the command line. The company also supplies a stand-alone GUI that developers can use to convert already deployed .Net applications and Web sites. The stand-alone GUI worked perfectly during my tests.

Each of these iNet conversion tools will make your life easier under different circumstances. For example, if you wanted to create and deploy a .Net-based Web site first, and then deploy a J2EE version on a different server, the plug-in within Visual Studio would be the best tool to do the conversion.

By contrast, the stand-alone GUI conversion tool might be a better fit if you have multiple .Net applications or sites already deployed and you want to convert them quickly to J2EE. The command-line tool is useful across all the platforms that iNet supports, but developers using Linux, Mac, or Unix will find it particular easy to use.

Following conversion, I deployed successfully to Linux, Windows, and Unix servers based on settings I entered into iNet's configuration wizard. Stryon's package also includes Apache Tomcat and MySQL for local testing of conversion and deployment, if needed.

Admittedly, iNet is not the ideal solution in every situation. For example, if you are using third-party .Net components, iNet won't convert them properly. Likewise, if you are using unmanaged code that runs outside the .Net framework, iNet can't help you. Stryon provides a detailed list of these cases so you can work around them -- and it promises to discover whether a work-around is possible. In the case of a third-party problem, Stryon may even work with that third party to provide a resolution if you request it.