The difference between the bottom-line value propositions of Java and .NET really come down to the fact that Java is platform independent at the cost of losing your programming language choices, while .NET is programming language independent at the expense of your operating system choices (of course Mono will reduce this burden over time somewhat).
With statement above in mind it's quite pleasing to see the emerging pool of .NET bridges for the Java Virtual Machine (basically tools that allow the use of Java Components within the .NET CLI (CLR and .NET bound languages e.g. C#, VB.NET, and others):
JavaBridge (awaiting url) - This is a .net package that is compiled into the VMLoader.dll; which must be referenced via the references feature of Visual Studio or from the commandline using the '/r:VMLoader.dll' switch.
JNBridgePro is a Java/.NET interoperability tool that enables new or existing Java code to fully participate in the cross-language development capabilities of Microsoft .NET (pronounced "dotnet"), while maintaining Java’s cross-platform capability and conformance to Java standards.
Key Difference! This appears to be a two-way (duplex) bridge.
JNBridgePro allows classes written in .NET languages, such as C#, C++, and Visual Basic, to seamlessly and transparently access Java classes as if Java were itself a .NET language, and enables Java to call .NET code through callbacks.
Hopefully I will get a minute to test these hands-on, or at least google for some published hands on experience (using real examples solving real programming problems).
Hats off the both vendors as Java the programming language shouldn't get lost in the battle of the distributed component runtime machines (a war that is taking shape between .NET and J2EE).
Combine either one of these tools with Virtuoso and you have the best of all worlds for .NET, J2EE, Operating Systems, and Databases. You never lose to freedom to 'mix and match' best of class critical IS infrastructure components (irrespective of the outcome of the Distributed Component Runtime war).
Your IS/IT infrastructure needs should never lead you down a database, operating system, or programming language specific cul-de-sac!
Never!