Export (0) Print
Expand All
Abortable Thread Pool
The Analytic Hierarchy Process
API Test Automation in .NET
Asynchronous HttpWebRequests, Interface Implementation, and More
Bad Code? FxCop to the Rescue
Basics of .NET Internationalization
Behind the Scenes: Discover the Design Patterns You're Already Using in the .NET Framework
BigInteger, GetFiles, and More
Binary Serialization of DataSets
Building Voice User Interfaces
Can't Commit?: Volatile Resource Managers in .NET Bring Transactions to the Common Type
CLR Inside Out: Base Class Library Performance Tips and Tricks
CLR Inside Out: Ensuring .NET Framework 2.0 Compatibility
CLR Inside Out: Extending System.Diagnostics
CLR Profiler: No Code Can Hide from the Profiling API in the .NET Framework 2.0
Concurrent Affairs: Build a Richer Thread Synchronization Lock
Custom Cultures: Extend Your Code's Global Reach With New Features In The .NET Framework 2.0
Cutting Edge: Collections and Data Binding
Const in C#, Exception Filters, IWin32Window, and More
Creating a Custom Metrics Tool
DataGridView
DataSets vs. Collections
Determining .NET Assembly and Method References
Experimenting with F#
File Copy Progress, Custom Thread Pools
Finalizers, Assembly Names, MethodInfo, and More
Got Directory Services?: New Ways to Manage Active Directory using the .NET Framework 2.0
High Availability: Keep Your Code Running with the Reliability Features of the .NET Framework
How Microsoft Uses Reflection
ICustomTypeDescriptor, Part 2
ICustomTypeDescriptor, Part 1
Iterating NTFS Streams
JIT and Run: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
Lightweight UI Test Automation with .NET
Low-Level UI Test Automation
Make Your Apps Fly with the New Enterprise Performance Tool
Managed Spy: Deliver The Power Of Spy++ To Windows Forms With Our New Tool
Memory Models: Understand the Impact of Low-Lock Techniques in Multithreaded Apps
Microsoft Java Virtual Machine Update
Microsoft .NET Framework Delivers the Platform for an Integrated, Service-Oriented Web, Part 2
Mini Dump Snapshots and the New SOS
Mutant Power: Create A Simple Mutation Testing System With The .NET Framework
NamedGZipStream, Covariance and Contravariance
.NET Internationalization Utilities
.NET Profiling: Write Profilers With Ease Using High-Level Wrapper Classes
No More Hangs: Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps
The Perfect Host: Create and Host Custom Designers with the .NET Framework 2.0
Phoenix Rising
Scheme Is Love
Security Enhancements in the .NET Framework 2.0
Sepia Tone, StringLogicalComparer, and More
Software Testing Paradoxes
Stay Alert: Use Managed Code To Generate A Secure Audit Trail
Stream Decorator, Single-Instance Apps
StringStream, Methods with Timeouts
SUPERASSERT Goes .NET
Tailor Your Application by Building a Custom Forms Designer with .NET
Test Harness Design Patterns
ThreadPoolPriority, and MethodImplAttribute
ThreadPoolWait and HandleLeakTracker
Three Vital FXCop Rules
A Tidal Wave of Change
To Confirm is Useless, to Undo Divine
Touch All the Bases: Give Your .NET App Brains and Brawn with the Intelligence of Neural Networks
Transactions for Memory
Trustworthy Software
Tune in to Channel 9
UDP Delivers: Take Total Control Of Your Networking With .NET and UDP
UI on the Fly: Use the .NET Framework to Generate and Execute Custom Controls at Run Time
Unexpected Errors in Managed Applications
Unhandled Exceptions and Tracing in the .NET Framework 2.0
Using Combinations to Improve Your Software Test Case Generation
Wandering Code: Write Mobile Agents In .NET To Roam And Interact On Your Network
What Makes Good Code Good?
XML Comments, Late-bound COM, and More
Expand Minimize

Moving Java Applications to .NET

 

Microsoft Corporation

May 2005

Applies to:
     Microsoft .NET

Summary:   Discover the advantages that Microsoft .NET offers over Java and learn how to convert Java applications to run with the Microsoft .NET Framework. (12 printed pages)

Contents

What Is .NET?
Comparing .NET to Java
How to Move Java Applications to the .NET Framework
Walkthroughs
Conclusion

What Is .NET?

Microsoft .NET (pronounced "dot net") is both a vision for how software should be written, and a set of tools for developing software that realizes this vision. To illustrate the driver for the Microsoft .NET vision, let's look at the common business problems of connectivity and interoperability: Most businesses cooperate with other businesses, yet their information systems operate in isolation. Product supply chains are not integrated across vendors; communication between supplier and purchaser is often limited to facsimile or simple text file exchange. This is often seen as a barrier to productivity improvements. When businesses become more connected, they can achieve greater efficiency. When every vendor in a supply chain is connected to each other, each can keep inventories at minimum, manufacture on an as-needed basis, and coordinate with greater efficiency.

Related to this is the issue of interoperability. Once businesses make the commitment to connect to each other, they are faced with the difficult engineering task of designing and implementing the connection when the cooperating systems are in different states of re-development or ongoing change. Added to this is the complexity of securing data as it is passed through corporate firewalls and exchanged with data from partners that are also competitors.

The Microsoft .NET vision is to better enable this capability: to make it simple to write systems that securely connect and interoperate with each other any time, any place, and on any device. The central technology for enabling this is XML Web services. This technology is both a methodology and transport layer for passing information between components on different machines, different networks, and different operating systems.

Support for XML Web services is widespread. A number of companies are already using XML Web services to connect with their partners. Microsoft is adding support for XML Web services across its entire product line. From a developer's point of view, Microsoft .NET makes it easy to write systems that connect with each other using Microsoft Visual Studio .NET, the .NET Framework, and XML Web services.

The .NET Framework

Microsoft .NET is much more than XML Web services. At the heart of Microsoft .NET is the .NET Framework, consisting of the common language runtime and the class libraries. These two components provide the execution engine and programming APIs for building .NET applications.

Applications compiled for the .NET Framework are not compiled directly to native code. Instead, they are compiled to an intermediate language called Microsoft Intermediate Language (MSIL). When an application is run for the first time, the common language runtime just-in-time compiler compiles the MSIL code into native code before it is executed. The common language runtime is more than a simple JIT compiler; it is also responsible for providing low-level execution services, such as garbage collection, exception handling, security services, and runtime type-safety checking. Because of the common language runtime's role in managing execution, programs that target the .NET Framework are sometimes called "managed" applications.

The .NET Framework also includes a set of classes for building applications that run on the common language runtime. These class libraries provide rich support for a wide range of tasks, including data access, security, file IO, XML manipulation, messaging, class reflection, XML Web services, user-interface construction, text processing, ASP.NET, and Microsoft Windows services.

Perhaps the most unique attribute of the .NET Framework is its support for multiple languages. Microsoft ships .NET compilers for four commercial languages: Visual C# .NET, Visual Basic .NET, the Managed Extensions for C++, and Visual J# .NET. Apart from these, support for over 20 programming languages including Perl, Python, and COBOL is available for use with the .NET Framework. Relying on the common language runtime, code compiled with these compilers can interoperate.

To help create languages for the .NET Framework, Microsoft created the Common Language Infrastructure specification (CLI). The CLI describes the features that each language must provide in order to use the .NET Framework and common language runtime and to interoperate with components written in other languages. If a language implements the necessary functionality, it is said to be .NET-compliant. Every .NET-compliant language supports the same data types, uses the same .NET Framework classes, compiles to the same MSIL, and uses the same common language runtime to manage execution. Because of this, every .NET-compliant language is a first-class Microsoft .NET citizen. Developers are free to choose the best language for a particular component without losing any of the power and freedom of the platform. In addition, components written in one language can easily interoperate with components written in another language. For example, you can write a class in C# that inherits from a base class written in Visual Basic. The CLI has been standardized by ECMA, encouraging many language developers to create .NET-compliant versions of many languages

Figure 1 shows how the different components of the .NET Framework sit on top of the operating system. The .NET Framework is composed of the four blue boxes—representing ASP.NET, Windows Forms, ADO.NET and XML, and subcomponents.

Figure 1. The .NET Framework architecture.

Visual Studio .NET

To enable .NET Framework development, Microsoft delivered a new set of development tools in Visual Studio .NET. Visual Studio .NET supports developing applications in single or multiple languages. The same integrated development environment (IDE) is used for designing, developing, debugging, and deploying .NET Framework-based components.

Visual Studio supports creating console applications, Windows applications, DLLs, Web applications, XML Web services, and applications for handheld devices. It provides some unique high-productivity features such as: IntelliSense; visual designers for Web Forms and Windows Forms, XML Schemas, and data; a cross-language debugger that seamlessly steps from code written in one language to another; tight integration with the .NET Framework; Dynamic Help that continually provides contextual Help as you type; a Task List that shows compiler errors and To-Do tasks; architecture design features such as Visio integration and a Server Explorer for visually accessing databases, Windows services, performance counters, and server-side application components. In addition, Visual Studio is extensible. Numerous third parties provide extensions (some free and some for-fee); there is an SDK to enable any developer to build custom extensions to the Visual Studio .NET toolset.

Microsoft .NET: References and Resources

Following are a list of references and resources for introduction and more detailed information regarding Microsoft.NET and various elements of the framework.

Microsoft .NET Product Page

Go here to download the .NET Framework SDK and find links to Microsoft .NET related information and products.

GotDotNet Community

GotDotNet is a community resource that contains sample downloads, tools, forums, links, and guides for the .NET Framework and related technologies.

ASP.NET Community

The ASP.NET site contains a collection of tools, community resources, samples, and tutorials specifically for ASP.NET application development. A rich component library is also available for building and extending your own ASP.NET applications.

Windows Forms Community

The Windows Forms .NET site is similar in nature to the ASP.NET site but is focused solely on Windows Forms development using Microsoft .NET.

Comparing .NET to Java

To seasoned Java developers, the .NET Framework may seem similar to the Java platform; both provide a structured way to create applications, both have languages that compile to intermediate code, and both provide a large library of APIs for application development. However, the .NET Framework has at its core a different set of goals than the Java platform.

Conceptually, Java is two things: the Java platform (runtime and APIs), and the Java language. The purpose of the Java platform is to support applications written in the Java language and compiled to Java bytecode. Although there have been attempts to compile other languages to Java bytecode, these have largely been academic exercises. For a long time, the ideal of Java has been a single language on multiple platforms.

.NET is also two things: the .NET Framework (runtime and APIs), and the plethora of supported programming languages. The purpose of the .NET Framework is to support applications written in any language and compiled to MSIL. The goal of the .NET Framework is a single platform shared by multiple languages.

How to Move Java Applications to the .NET Framework

There are two recommended paths for moving Java applications to the .NET Framework: upgrade them to Visual J# .NET, or convert them to Visual C# .NET. Each approach requires a different effort, and each has different benefits as outlined below. Both approaches also mean moving the application to Microsoft Windows, since the full version of the .NET Framework is available only for Microsoft Windows. Although conversion from Java to the .NET Framework can be performed using the .NET Framework SDK, using the command-line compilers for Visual C# .NET, Visual Basic .NET, and Visual J# .NET, the remainder of this document assumes the developer is using Visual Studio .NET to move applications to the .NET Framework.

Upgrade to Visual J# .NET

Visual J# .NET is an implementation of the Java language for the .NET Framework. It is available from MSDN's Visual J# site.

Developed independently by Microsoft, J# compiles Java language code to MSIL. Visual J# .NET consists of a Java language compiler and class libraries designed to provide the functionality equivalent to most of the JDK level 1.1.4 packages. The classes in the java.util package support functionality equivalent to JDK level 1.2 class libraries and classes in the Microsoft Supplemental UI Library for Visual J# provide much of the functionality as described in the Java 2 JFC Swing specification. It also consists of a tool to upgrade compiled Java byte code to MSIL—useful for upgrading libraries to a form that can be used from .NET Framework-based applications. In addition, like other .NET-compliant languages, Visual J# .NET has full access to the .NET Framework, and includes designers for Windows Forms and ASP.NET Web Forms development.

In many cases, especially where business logic preservation is a goal, upgrading to Visual J# .NET is the easiest and quickest way to move Java applications to the .NET Framework. With a familiar syntax and set of class libraries, developers can leverage their existing knowledge of Java, and become productive on the .NET Framework immediately. Applications upgraded to Visual J# .NET are in a position of instant benefit: The upgrade is very quick, and developers can begin to add features made possible with the .NET Framework and Microsoft extensions to the Java language. The Java to Visual J# .NET Upgrade Wizard is invoked by opening a Visual J++ 6.0 project with Visual Studio .NET.

Convert to Visual C# .NET

The Java Language Conversion Assistant (JLCA) is available for download from the Java Language Conversion Assistant site. The Java Language Conversion Assistant converts Java applications to Visual C# .NET. Code that calls Java APIs is converted to comparable C# code that uses the .NET Framework. Because of the complexity of the conversion, not all Java APIs are converted. The Java Language Conversion Assistant converts about 90 percent of JDK and J2EE level 1.3 calls, EJB, JAAS, JCE, JMS, JNDI, RMI, and JAXP, and emits issues in code for the other 10 percent. Each issue is linked to a topic with guidelines for what modifications to make to finish the conversion.

Applications converted from Java to C# are in a position of maximum flexibility: Although converting to C# is generally more labor-intensive than upgrading to Visual J# .NET, it offers more opportunity because the application is converted to use the native .NET Framework APIs. After the modifications are made, converted code will immediately take advantage of the improved performance, scalability, security, and versioning of the .NET Framework, just as with Visual J# .NET.

Unlike Visual J# .NET, the Java Language Conversion Assistant supports conversion of Visual J++ 6.0, loose-file, and directory-based projects. The Java Language Conversion Assistant is invoked by choosing File, then Open, and then Convert... from the Visual Studio .NET menu.

To obtain the latest version of the Java Language Conversion Assistant, visit the MSDN site here. Version 3.0 of the Java Language Conversion Assistant is in beta at the time of writing of this article, but the beta quality is very high and produces better results than versions 1.0 and 2.0.

Choosing Between J# and C#

Deciding which .NET-compliant language to migrate your Java applications to is predominantly a matter of personal choice. As discussed earlier, both Visual J# .NET and Visual C# .NET compile to the same MSIL, both languages have access to the same .NET Framework, and both languages offer relatively similar capabilities.

To help you with making the choice, here are three major determining factors to consider when choosing between upgrading to Visual J# .NET and converting to Visual C# .NET:

Table 1

Migration time When a Java application is upgraded to Visual J# .NET, the language stays as Java, and calls to JDK level 1.1.4 API functionality, JDK level 1.2 java.util package API functionality, and Java 2 JFC Swing specification supported by J# are preserved as-is. When the same application is converted to C#, the language is converted to C# and Java API calls up to JDK level 1.3 APIs are converted to native .NET Framework calls. The quality of this conversion is very high (often upwards of 90%), but this still means some modifications after the Java Language Conversion Assistant has finished. If reducing the migration time is critical, then Visual J# .NET may be the best option.
Framework Applications converted to C# immediately have the advantage of being on the new .NET Framework, with improved performance, scalability, security, and versioning over the Java platform. Applications upgraded to Visual J# .NET continue to use Java datatypes and Java libraries, although you can add new functionality with the .NET Framework. If it is important to move your application architecture to take advantage of the .NET Framework, then C# may be the best option.
Language For many people, the most important consideration is simply language preference: whether you want to develop your application using Java or C#. This is predominantly a matter of personal choice. Both Visual J# .NET and C# derive from C++ and have comparable grammar and similar capabilities. Visual J# .NET may be the best choice for people who have invested in Java and want to continue using Java. C# may be the best choice for developers who want to move to a "native" .NET-compliant language designed specifically for developing .NET applications.

To understand more about each option, the next section examines what happens to your application when it is moved to .NET.

Technology Mappings

Each migration path generates a different result. The following two tables show what happens to the composition of Java projects when they are migrated to the .NET Framework.

Table 2. Java to .Net component migration.

Java Technology Upgrade to Visual J# .NET Convert to C#
Java language Java language C# Language
Applet Supported via J# Browser Controls Windows Forms control
JavaBean JavaBean System.ComponentModel

System.Windows.Forms.UserControl

ActiveX control Supported via J# Browser Controls ActiveX control
AWT frame AWT frame Windows Form
WFC form WFC form Windows Form
Compiled library Compiled library Not converted
Resource file ResX file ResX file
CORBA Not Converted .NET Remoting

System.Runtime.Remoting;

RMI and RMI IIOP Not Converted System.Remoting

System.Security

System.MarshalByRefObject

DHTML Not Converted System.Web.UI.WebControls
Enterprise Java Bean Not Converted System.EnterpriseServices
Java Authentication and Authorization Service Not Converted System.Security
JavaBeans Activation Framework Not Converted System.Windows.Forms.DataObject
Java Mail Not Converted System.Web.Mail
Java API for XML Processing Not Converted System.Xml
Java Cryptography Extension Not Converted System.Security.Cryptography
Java Database Connectivity Not Converted System.Data.OleDB
Java Messaging Service Not Converted System.Messaging
Java Naming and Directory Interface Not Converted System.DirectoryServices
Java Server Pages Not Converted ASP.NET
Java Transaction API Not Converted System.EnterpriseServices
Microsoft Transaction Server Not Converted C# Class (Serviceed Component)

Table 3. Migrations for individual packages.

Package Upgrade to Visual J# .NET Convert to C#
com.ms.awt
java.awt
Java.awt System.Windows.Forms
com.ms.com com.ms.com System.Runtime.InteropServices
com.ms.dll com.ms.dll System.Runtime.InteropServices
System.ComponentModel
com.ms.dxmedia Not Upgraded DirectAnimation
com.ms.fx Not Upgraded System.Windows.Forms
com.ms.io com.ms.vjsharp.io System.IO
com.ms.lang com.ms.lang System
Microsoft.Win32.RegistryKey
com.ms.object com.ms.vjsharp.object System
com.ms.ui Not Upgraded System.Windows.Forms
com.ms.util com.ms.util System
System.Collections
System.Diagnostics
com.ms.wfc.app com.ms.wfc.app System.Windows.Forms System.Globalization.CultureInfo Microsoft.Win32
System.Environment.SpecialFolder
System.Threading
System.DateTime
com.ms.wfc.core com.ms.wfc.core System
System.ComponentModel System.Windows.Forms.Design System.ComponentModel.Design System.Resources
com.ms.wfc.data com.ms.wfc.data ADODB
System.Runtime.InteropServices
RDS System.Globalization
System
System.ComponentModel
MSDASC
System.Resources
com.ms.wfc.data.adodb com.ms.wfc.data.adodb ADODB
com.ms.wfc.data.ui com.ms.wfc.data.ui System.Windows.Forms
System.Data
System
com.ms.wfc.io com.ms.wfc.io System.IO
System.Globalization
com.ms.wfc.ole32 com.ms.wfc.ole32  
com.ms.wfc.ui com.ms.wfc.ui System.Windows.Forms
com.ms.wfc.util com.ms.wfc.util System
System.Diagnostics
System.Collections System.Runtime.InteropServices System.Resources
System.Globalization
com.ms.wfc.win32 com.ms.win32 com.ms.wfc.win32 com.ms.win32 Converted to PInvoke calls
java.io Java.io System.IO
java.lang Java.lang System

System.Threading

java.lang.reflect Java.lang.reflect System.Reflection
System
java.math Java.math System.Decimal
java.net Java.net System.Net
System
System.IO
java.security Java.security Not Converted
java.sql Java.sql System.Data.OleDb
System.DateTime
java.text Java.text System
System.Globalization
System.Resources
java.text.resources Java.text.resources System.Resources
java.util Java.util System
System.Collections
System.Globalization
System.Resources
System.Configuration
javax.swing javax.swing System.Windows.Forms

Mixed-Mode Migrations

Components written in different .NET-compliant languages can effortlessly interoperate with each other. This makes mixed-mode migrations from Java possible. In a mixed-mode migration, you upgrade one component of an application to Visual J# .NET, and convert another to C#. Practical examples include upgrading a middle-tier component to Visual J# .NET and accessing it from a client converted to C#. You can also use the Visual J# .NET Binary Converter to make libraries available to any .NET-compliant language.

Technologies with No Automatic Migration

Both Visual J# .NET and the Java Language Conversion Assistant target the Java Language, supporting conversion from JDK 1.1.4 and J2EE v1.3, respectively. In addition, Visual J# .NET supports the Microsoft libraries that shipped with Visual J++ 6.0, and both Visual J# .NET and the JLCA support a few extensions beyond that base. Some Java applications that use technologies from later versions of Java may require some additional modifications to migrate them to the .NET Framework. This is usually very simple: After migration, the greater part of the application (business logic and JDK level 1.1.4/1.3 classes as appropriate) will have migrated perfectly. The unsupported technologies will be left unchanged in the migrated code. To finish the migration, you replace the unmigrated Java technology with comparable Microsoft .NET technology. Because the .NET Framework provides a richer set of classes than what is available in Java, often you can make some significant enhancements when performing the technology replacement

Migrating Java Server Pages

Java Server Pages (JSP) and Servlets are both technologies for creating Java-enabled Web pages. JSP provides a script embedded HTML architecture similar to ASP. Servlets offer a mechanism for compiled JSP pages without HTML code. Both items employ Java code, and both offer event-based programming for Web pages.

Both JSP and Servlets can be migrated to ASP.NET. A JSP to ASP.NET Migration Guide using Java Language Conversion Assistant is available at the JSP to ASP.NET Migration Guide site.

Java Migration: References and Resources

Following are a list of references and resources for introduction and more detailed information regarding Visual J# .NET and Java Language Conversion Assistant.

Visual J# .NET Product Page

Go here for more information regarding product documentation, tools, forums, links, and guides for Visual J# .NET.

Java Language Conversion Assistant Product Page

Go here for more information regarding Java Language Conversion Assistant product documentation, knowledge base articles, links, and guides.

Resources for Java Developers

Go here to access resources for Java Developers migrating to Microsoft .NET.

Community

In case you have a query, post the same to the MSDN Forums at http://forums.microsoft.com/msdn Most importantly, in case you have any questions, comments, can not find what you're looking for, or have requests for additional content, please let us know by dropping us a line at Java-NET@Microsoft.com.

Walkthroughs

This section provides links for walkthroughs to upgrade from Visual J++ 6.0 to Visual J# .NET and conversion from Java to C#. The purpose of these sections is to introduce you to the migration techniques.

How to Upgrade a Visual J++ 6.0 Project to Visual J# .NET

Samples of how to upgrade a Visual J++ 6.0 project to Visual J# .NET are available at the Visual J# .NET Samples site.

How to Convert a Java Project to C#

Samples of how to convert a Java project to C# and .NET are available at the JSP to ASP.NET Migration Guide site.

Conclusion

The Java to Visual J# .NET and Java to C# migration tools make moving Java applications to .NET easy and cost-effective. In addition, all the benefits of the .NET Framework are immediately available to your migrated applications, enabling developers to more quickly add new capabilities to existing applications, offering simplified deployment and maintenance for operators and administrators, and allowing end users to enjoy the improved user experience that .NET Framework-based applications have over applications running on the Java platform.

When moving to the .NET Framework, developers may either upgrade their applications to Visual J# .NET or convert them to C#. Each method has its advantages: upgrading to Visual J# .NET is the quickest and easiest option, delivering instant benefit to the Java application; converting to C# is a slower option, but delivers maximum flexibility to the converted application. The choice of whether to use Visual J# .NET or Visual C# .NET depends on the particular situation.

Choosing either migration technique will add new life to your legacy applications. Visual Studio .NET and the .NET Framework represent a new era in software development.

Show:
© 2014 Microsoft