Visual MainWin offers best of both .Net, Java worlds

When I first heard about Mainsoft’s Visual MainWin for J2EE, I thought the concept was a harebrained idea. Just skimming some of the product’s help topics sent me reeling: “Developing ASP .Net applications on J2EE.” Give me a break.

Experimenting with the product put my sarcasm through a cleansing acid bath: If Visual MainWin for J2EE is a harebrained idea, it is the best-executed harebrained idea I’ve seen.

In a nutshell, Visual MainWin turns .Net applications into Java applications. But Visual MainWin for J2EE allows you to build ASP .Net apps — ones that use ADO (ActiveX Data Objects) .Net — and convert them to J2EE apps, deploy them to and debug them on J2EE app servers, and do it all from within Visual Studio .Net.

Visual MainWin for J2EE installs as a plug-in to the Visual Studio .Net IDE (integrated development environment). It also installs the included Tomcat 5.0 application server, which becomes the test bed for ASP .Net apps transformed into J2EE apps.

The word seamless has become nearly meaningless, but Visual MainWin’s integration into Visual Studio deserves the label. Visual MainWin attaches itself to the output of the compilation process and translates the IL (intermediate language) code coming out of Visual Studio into the equivalent Java bytecode. It packages the code into the proper archive file, depending on the target app server, and deploys the archive to the app server, along with Java versions of the ASP .Net and ADO .Net libraries.

Thus, MainWin turns Visual Studio .Net into a “develop, debug, and deploy” IDE for J2EE apps, with the peculiar twist that those apps can be written in VB (Visual Basic) .Net or C#.

Aside from the Visual MainWin project templates added to Visual Studio, you hardly know Visual MainWin is there. You can use all the server-side controls from ASP .Net. ADO .Net is implemented on top of JDBC, and the latest release of Visual MainWin provides a generic database connection.

What’s even more amazing is that the product wires the bytecode back to the .Net source for debugging purposes; you can single-step through C# or VB .Net source as Java bytecode executes. Not only is the translator converting IL code to bytecode, it’s preserving the debug information — an unexpected plus.

Visual MainWin does its best to map .Net entities to Java equivalents but must sometimes make exceptions — for example, in the case of exceptions. Java provides one exception class, but .Net provides three; Visual MainWin is forced to map all three .Net exceptions to the single Java exception. There’s no easy fix; you simply have to write around this many-to-one mapping.

Although all .Net exceptions are derived from the System.Exception class, not all Java exceptions are derived from java.lang.Exceptions; some generated by the JVM (Java Virtual Machine) are derived from the java.lang.Error class. This incongruence shows up in .Net code that tries to catch all exceptions. When translated into Java, exceptions derived from java.lang.Error slip by.

This is where Visual MainWin’s conditional compilation constants — JAVA and NET — come in handy. JAVA is true when the output of compilation is Java bytecode, and NET is true when the output is Microsoft IL. Use of these compilation constants allows you to create platform-agnostic source code. You can even import EJB references into a .Net project and call EJBs from VB .Net or C# code with Mainsoft-supplied wrapper code.

Visual MainWin for J2EE is remarkable; it is clever and smooth, and the exception-related write-arounds are but minor annoyances. At the very least, this opens the world of Linux to ASP .Net apps, and those results will be very interesting to watch.