Would you believe a migration from .NET to J2EE ? Well, direct software translators from .NET to J2EE compatible JVM code (yes – all the EARs, WARs, and JARs are done for you in well tied together deployments) are popping up like mushroom pods in the Fall. The two most prominant are from Mainsoft and from Stryon. And both converters which fit right into Visual Studio 2003 have gotten top mark reviews from InfoWorld (see October 10, 2004 issue page 331 for the Styron iNet 1.1 review).
Mainsoft was first to deliver a product earlier this year with Visual MainWin. Right in Visual Studio 2003 , mainWin takes over at the design and then deployment stage and translate .NET CLR to JVM with all the deployment trimmings. In fact, MainWin is so versatile it provides full debug capability of J2EE code within Visual Studio. Infoworld and Gartner are raving about the product and major OEMs such as CA, Cadence, Siebel, and many others are using it to port their .NET code to J2EE.
Like MainWin, Stryons iNET is a complete Java-based implementation of the Microsoft.NET framework, enabling programs written in .NET to execute in any Java-enabled environment, including Unix, Macintosh and Linux operating systems and leading application servers such as WebSphere, WebLogic, SunONE, JBoss, and Oracle 9i. But Stryon does not stop here it has iASP which allows users to port ASP code to Java and iHUB which acts as a two-waybridge between .NET and Java code which includes applications, Web services, Servlets, EJBs, COM/MTS components, JavaBeans, etc. Both vendors emphasize four common advantages to their .NET to J2EE converter products – greater stability, increased security, better performance, and better scalability.
Who Is Embarrassed Most ?
The question is who is embarrassed most by this turn of events ? Microsoft cannot be enamored of the fact that a)Visual Studio is being used to port .NET and other apps to Java and J2EE. – and b)OEMs and major corporates are taking advantage of the code. But partially this is a problem of Microsofts own brewing. Their developers have failed to eat their own dog food – with major tools like Office 2003 bypassing .NET code. And the programs that are using .NET – SQL Server 2005 for example – are very late indeed. Part of the lateness may be the battle going on between between the C# and C++ camps in the .NET world:
“There are two big messages that come through when you examine the upcoming Visual C++ 2005 compiler and the C++/CLI language design. Firstly, Visual C++ is positioning itself as the lowest level programming language for targeting the CLR. There should be no cause to use any other language, not even Microsoft intermediate language (MSIL) [or C#]“
A new version of C++ called C++/CLI will emerge with Visual Studio 2005. This means systems programmers will have to choose between coding in 4 system languages in the Redmond world: 1)native C++ or unmanaged C++, 2)managed C++, 3)C++/CLI and 4)C#. And as one can see from the note above the languages are distinctly different in the all important areas of memory management and try/catch/finally plus exception handling. Indeed, availability, reliability, security, and performance are on the front lines of changing coding practices at Redmond.
The Java developers have to be embarrassed too. Are some companies migrating to Visual Studio for faster development times given the vaunted difficulties of J2EEs EJB-Enterprise Java Bean development? Well all of the major Java vendors are going on a simplification and ease of development kick. Sun is promising to make Java Studio Creator as easy to use as Visual Basic. In our first review for ADTMag we were impressed with the effort (but not JSCs lack of support for other popular J2EE servers like Websphere , Weblogic, JBoss, Oracle, etc). But BEA, Oracle, IBM , Compuware and Borland among others are not resting on their laurels. For example, BEA WebLogic WorkShop, IBM Eclipse, and Oracle JDeveloper have all made notable advances in ease of development. In fact some of these tools appear to be better poised to deliver SOA and ESB capabilities than their .NET or other J2EE counterparts. But that is a massive review which no major IT journal has seen fit to take on.
So the bottom line is the jury is still out on how embarrassed the Java developers should be. Meanwhile MDA and code generation tools, especially vertically integrated (generating code for retail sector or the telecommunications or the light maufacturing industries) is starting to take off again. Just look at Microsofts Software Factories and the VC capital going into vertical maket developers. In sum, the .NET versus J2EE may become more of a sideshow while the main event moves on. Conversion utilities like MainWin and iNet are usually signs of the changing winds.