Java language support

I just noticed that the VJ# Developer Center has been updated recently to show the J# MVP’s.  It is exciting to read about the MVPs who are out there helping in the developer community every day.  Since I’m on the subject of J#, I wanted to take this opportunity to write down my thoughts on J#.   


When we set out to build the .NET Framework we understood that the industry was facing enormous challenges with heterogeneous environments.  One way we addressed this was of course with our investments in supporting Web services standards, which makes integration with disparate systems much easier.  But another challenge organizations face is with code and developer skills that span a wide range of heterogeneous systems.  Both code and skills can be expensive to build and maintain, so naturally customers want to leverage as much existing code and skills as possible when adopting a new solution.  So with the .NET Framework, our multiple language support enables developers of virtually all backgrounds to use the language they know – be it C++, Java, or even COBOL – and even migrate some or all of their existing code to run within the .NET Framework.


J# is a very important component of our language strategy and is getting even more important as more Java developers learn about the benefits of the .NET Framework.  Take a look at some of the companies who have ported large Java solutions to the .NET Framework by using J#. Without J#, these customers would have faced longer development times and increased migration costs. Every day we are out demonstrating the value proposition of the .NET Framework – and as long as Java developers are coming to our platform, we’ll have tools such as Visual J# and the Java Language Conversion Assistant(JLCA) to help them get here. I’m excited about the enhancements we’re making to Visual J# and the JLCA in Visual Studio 2005. For example, Visual J# is adding support for more Java-language keywords, implementing better JDK library functionality, adding support for generics consumption, and is becoming a full CLS Extender. The JLCA 3.0 release, which will be included with Visual Studio 2005, adds support for converting J2EE applications, including constructs like EJB’s, to C#. These are just some of the enhancements we’re making to help Java developers feel more at home in the world of the .NET Framework. You can visit Resources for Java developers to find migration, interoperability, and getting started resources for Java developers interested in the .NET Framework.



Comments (5)

  1. M says:


    With the Microsoft/Sun settlement what role will J# play in the future? Why can’t there be a Java.NET? Why need JCLA?


  2. Wayne Citrin says:

    Hi Soma,

    There are also third-party interoperability tools like our JNBridgePro that allow companies to start building .NET projects while keeping their Java code, too. In some ways, these interop tools have advantages over tools like J# and JLCA, since they allow companies to get started on their .NET projects without the time and expense of converting their Java code. In addition, interop can be done even if the Java source is unavailable. Finally, because there’s no conversion, there’s no chance of errors being introduced in the conversion process. In other words, the barriers keeping such companies from starting with .NET are greatly lowered.

  3. S. Somasegar says:

    Wayne – thanks for your comments. Yes, interoperability is definitely a great first step for many customers depending on their goals and constraints. We list 3rd party Interoperability tools and resources – including JNBridge – on our Java Interop page here:

  4. css says:

    I tried JNBridgePro on a project a few weeks ago. It’s actually a pretty decent product (I was calling C# from Java in shared memory mode). Start up time was a little slow but other than that no complaints.