That's because the quiet ripples of what I call Java.NET convergence have turned into a wave. New 'bridgeware' offerings, such as cross-compilers, are appearing in the marketplace while platform vendors themselves are also releasing Java/.NET bridge tools.
This creeping convergence of the Java-J2EE platform and Microsoft's .NET has developers around the world discussing what it means for their futures and where they should place their allegiances.
What exactly are the forces driving the convergence of .NET and Java?
One is the Microsoft Intermediate Language, which is the input for the Common Language Runtime technology at the core of .NET. MSIL opens up many cross-compiler possibilities -- with the end result targeting both .NET and Java. Such possibilities include MSIL-to-JVM byte code, MSIL-to-Java, and Java-to-MSIL. And that's just for starters.
Who benefits?
Any convergence of any kind, in either direction, probably favours Microsoft. Because Java is the established incumbent, any activity, whatsoever, is a net positive for the challenger. Consider the following:
- Any convergence work by developers will spur at least some use of Visual Studio.Net. And with Visual Studio.Net finally shipping this week -- and positioned as the de facto, best-of-breed integrated development environment --convergence work done using VS.NET clearly favors Microsoft.
- Java developers will be immediately productive in the .NET environment. Here's why: Because the advanced object and language features of Java/J2EE and C#/.NET are virtually identical, Java-enabled developers making the .NET leap will have a much easier time compared to the traditional Microsoft (read: VB) developer.
-
Any Java developer who actually does jump to .NET is -- at least in theory -- one less developer building apps for J2EE.
- Lastly, and perhaps most importantly, budget-conscious CIOs seriously considering .NET will be looking for ways to leverage (and in some ways appease) developer interest in Java while getting .NET applications built.
Other recent developments in the Java.NET convergence space also suggest how all this might end up.
Microsoft has released the JUMP toolkit and J#.NET, making it as simple as possible to move from Java to C#. The C# language itself is designed to make Java ports quick, simple, and painless.
Halcyon Software has released iNET, a C#-to-JVM byte code translator, which plugs into the Visual Studio.Net suite of tools. iNET allows C# to be used to generate JVM byte code, later be executed within a Java Virtual Machine. The hook here is that the developer is targeting the Java runtime but working, learning and building in .NET languages.
Remotesoft has released Java.NET, a tool for running native Java code within the .NET environment. This convergence tool targets .NET as the runtime environment for the resulting application, written in Java. The product includes .NET-language access to Java class libraries and translation of native Java source to .NET-compatible C# and MSIL.
The implications are pretty plain.
By design, MSIL practically begs to be translated and cross-compiled. That's going to lead to the wide availability of tools that do exactly that.
You can expect IT budgets to develop for two predominant platforms: J2EE, and .NET. You can, accordingly, expect IT managers to strongly value -- and therefore demand -- robust, cross-platform translation tools.
That demand will spawn new convergence tools. On balance, this means Microsoft will likely emerge as the winner since J2EE and Java are the incumbents and -- quite literally -- the target to shoot at.
Dan Mezick is President of New Technology Solutions, a software development and training company. You can reach him at Dan.Mezick@NewTechUSA.com.
