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.
While I was converting my applications and Web sites, it occurred to me that iNet helps enterprises in another way, too. For most IT sites, using both J2EE and .Net is the norm. However, some less experienced developers may not yet feel comfortable using J2EE development tools such as BEA Systems's WebLogic Workshop or IBM's WebSphere Studio. In these cases, iNet can provide a bridge to help less experienced developers create J2EE applications using Visual Studio .Net.
Of course, iNet isn't the only game in town for those who wish to convert .Net applications to J2EE. Mainsoft Corp.'s Visual MainWin provides some stiff competition. Both tools do a good job, so pricing may help you decide. For companies deploying to J2EE environments on Linux or Windows, Stryon provides a lower price point (US$995) compared to MainWin (US$5,000 per developer regardless of platform). On Unix, midrange, and mainframe platforms, where iNet costs US$9,995 and US$19,995 respectively, MainWin becomes the low-price champ.
My only serious complaint with iNet is that its Web-based documentation fails to provide the level of detail that developers unfamiliar with J2EE will need. For example, if a conversion process does not complete successfully, don't bother looking for information in the online help to guide you through the troubleshooting process; it's not there. Also, within the IL2Java plug-in that's surfaced within Visual Studio .Net, the addition of online help and an initial tutorial would be useful enhancements.
Documentation aside, iNet is a solid and useful tool that supports higher performance, server consolidation, scalability, and security. In addition, it can act as a bridge for developers who need to deploy J2EE applications and Web sites while enjoying the comforts of working with Visual Studio .Net.
IT sites that plan to leverage .Net to J2EE conversions as part of their core application strategy will want to evaluate iNet alongside its rival MainWin. Because both tools are on par for J2EE conversion tasks, check comparative prices for the platforms you need. Both iNet and MainWin require work-arounds for some applications and Web sites, so a proof-of-concept project that includes several conversions is definitely warranted.