Moving from WFC to the .NET Framework
Dr. Bruce E. Krell
SWA Engineering, Inc.
Summary: Microsoft's Java-language development tool for Visual Studio® .NET, Microsoft® Visual J#® .NET, enables a programmer to access the .NET Framework and build applications using the Java language. Visual J# .NET is rich in features and capabilities and also enables greater productivity. This paper provides an overview and comparison of the architecture and feature set of the Windows Foundation Classes (WFC) library and the .NET Framework class library. (8 printed pages)
Current Status of WFC
.NET Framework Architecture
Similarities and Differences Between J++/WFC and J#/.NET Framework Classes
Benefits of Transition
With the release of Visual J++® 6.0 several years ago, Java programmers could provide a much richer user interface using a library called the Windows Foundation Classes (WFC). This library also provided a much greater capability for backend programming access to hardware and other external interfaces, enabling Java programmers to obtain greater productivity and shorten the time to deliver their products to the marketplace. With the release of Visual J# .NET and the access it provides to the .NET Framework, developers gained even richer features and capabilities and increased productivity.
This paper provides developers with the background information to migrate J++ applications to J# and the .NET Framework. It also provides a high-level but useful comparison of the WFC and .NET Framework class architectures, which enables a better understanding of the impact and advantages of switching from J++ and WFC to Visual J# .NET and the .NET Framework.
Before comparing the two basic architectures, a couple of caveats are important. When migrating J++ applications to Visual J# .NET, most WFC applications will just work about 95 percent of the time without change. J# does provide support for WFC functionality, J/Direct®, and most other Microsoft-specific classes found in Visual J++ 6.0. However, some limitations do exist for this support. The visual design capabilities of Visual Studio .NET do not apply to the components defined by WFC. This means that, for example, you cannot drag these components from a toolbar and drop them on a palette to rapidly create an application. Moreover, the WFC libraries will remain exactly as they are implemented today because Microsoft does not intend to enhance WFC in any way in the future. In fact, the WFC classes will likely be deprecated in a future version of the J# class libraries. Most importantly, as a developer, you should take advantage of the many benefits of using the .NET Framework classes, which are outlined in the remainder of this paper.
The WFC library is a set of packages. These packages include one or more classes that organize the methods and capabilities into useful groups. A summary of some of the more important packages is contained in the following table.
|Package Name||Package Capabilities|
|com.ms.wfc.app||Supports application operations such as threads.|
|com.ms.wfc.core||Provides the basis for WFC classes, such as component and event.|
|com.ms.wfc.data||Accesses ActiveX data objects and data formatting.|
|com.ms.wfc.data.ui||Implements and supports data bound controls.|
|com.ms.wfc.html||Accesses dynamic HTML elements through object model.|
|com.ms.wfc.io||Provides classes for working with files and data streams.|
|com.ms.wfc.ui||Provides classes for user interface components.|
|com.ms.wfc.util||Includes miscellaneous utilities such as data conversion.|
com.ms.wfc.ui.Brush, and so on
|Classes for utilizing various drawing tools, such as pens.|
Three of the packages mentioned in the previous table deserve special consideration. The ability to provide a user interface appears in the package com.ms.wfc.ui. This package contains forms and standard controls such as buttons, text boxes, and labels. Another important package is com.ms.wfc.data. When a program uses classes in this package, the application can easily access databases such as Microsoft Access and Microsoft SQL Server. Another package useful to an application programmer is com.ms.wfc.html. This package contains classes that enable Web servers and components to generate Web page interfaces programmatically from within structured, compiled Java-language source code.
Another important aspect of the WFC architecture is the inheritance hierarchy that WFC provides. The following is an example of a portion of this hierarchy.
Figure 1. Class Hierarchy for Form Class
Within WFC, only three levels of hierarchy take the programmer directly to the Form class. As with any inheritance hierarchy, the leaf class, Form, receives all of the methods and properties provided by the ancestor classes. Notice that all of the properties are implemented with set and get methods. Also, the Form class natively provides the ability to automatically scroll the contents of its client area, simply by setting the AutoScroll property through the set method provided. The ability for the programmer to control the size of the actual form is inherited from the parent Control class.
The basic element of the .NET Framework classes is the assembly. An assembly provides a means for organizing classes and methods into deliverable components, similar to the package concept in WFC. Generally speaking, programmers can simply treat assemblies as black boxes that house collections of classes.
|Assembly Name||Assembly Capabilities|
|System.Threading, System.Event||Supports applications operations such as threads and events.|
|System.Windows.Forms||Provides basis for Windows classes, such as forms.|
|System.Data||Accesses ADO.Net data objects and data formatting.|
|System.Windows.Forms.DataGrid||Implements and supports data bound controls.|
|System.Web.UI||Accesses HTML elements through an object model.|
|System.IO||Provides classes for working with files and data streams.|
.Button, System.Windows.Forms.ListBox, and so on
|Provides classes for user controls and interface components.|
|System.Math, System.Convert||Includes miscellaneous utilities such as data conversion.|
|System.Drawing||Classes for utilizing various drawing tools, such as pens.|
Similar to the list of packages in WFC, the previous table contains a list of the primary .NET Framework assemblies most frequently used by J# application programmers. This list of assemblies compares quite favorably with the list provided for WFC. One assembly named System.Windows.Forms provides the set of classes that allows a program to display a window with an attendant set of child controls. Another assembly, System.Data, enables access to ADO.NET data objects, providing a simpler programmatic access to practically any data store imaginable, including Access, SQL Server, Oracle, Open Database Connectivity (ODBC), OLE DB, and even raw XML. A new and improved assembly, System.Web, provides the ability for Web-hosted components to generate HTML elements on a Web page rendered to the user. The Web forms classes, collectively known as ASP.NET, dynamically generate markup based on the type of client making a request. For example, if a browser supports DHTML and client-side scripting, ASP.NET will render the form using that support for a richer experience. But when a client without the more advanced support views the page, ASP.NET will still render the form properly using an older version of HTML. This functionality is provided "automatically" for the developer, since the developer designs the page once and the ASP.NET forms controls will handle the proper rendering.
The following figure traces the inheritance hierarchy that leads to the System.Windows.Forms.Form class. Through the inheritance hierarchy, the same set of capabilities is available to programmers that utilize this class in an application.
Figure 2. Class Hierarchy for Form Class
The classes in this hierarchy reveal some important implications to the .NET Framework classes. A larger number of ancestor classes leads to the Form class, indicating that the .NET Framework classes are a far richer, more capable, improved set of classes over WFC. At the programming level of the Form class, all of the same features are available to the J# programmer.
Most J++ programmers are likely to be concerned that switching from J++/WFC to J#/.NET Framework requires learning a whole new library and set of features. The following table provides a quick comparison of the major programming elements in WFC and .NET Framework and should relieve this concern.
For example, consider the capabilities provided in both contexts that a programmer uses to create a program that displays a window to the user. In WFC, deriving from the class com.ms.wfc.ui.Form provides the J++ application a basic window and an underlying message processing pump. Similar capabilities are provided in J# using the class System.Windows.Forms.Form. The only difference in both usage and behavior between these two classes is the prefix in the context that leads to the Form class.
Another important example demonstrated in this table is the Event Handler element. This table contains the delegate name for a method that is instantiated to process custom painting requirements. Both WFC and the .NET Framework use the delegate concept and the same signature and arguments for these event handlers. Therefore, the J++ programmer will be right at home transitioning from WFC to the .NET Framework classes after becoming accustomed to the change in context prefixes.
In addition to the similarities and differences between J++/WFC and J#/.NET Framework classes described in the previous architecture discussion, there are other useful comparisons between the two .
Many applications require direct access to the underlying Win32 API. The mechanism for accomplishing this within WFC is called J/Direct. Access to the underlying API methods utilizes the
dll.import directive. This mechanism is so useful that the common language runtime (CLR) also provides this capability. This feature is called P/Invoke. The declaration has changed somewhat because it's called System.Runtime.InteropServices.DLLImport, but the usage approach is similar to that in WFC.
Reuse is an important element of any programming environment. Since a huge number of reusable components have been implemented via ActiveX in both C++ and Visual Basic, both WFC and .NET Framework classes provide the capability to utilize these components. Within WFC, a tool named JActiveX is integrated into Visual J++. A similar tool named aximp is integrated into Visual J# .NET. These tools work in a similar manner. Both tools generate a native wrapper class that enables the programmer to programmatically access the underlying control without worrying about all of the hosting headaches. Incidentally, the wrapper class generated by JActiveX uses the WFC class com.ms.wfc.ui.AxHost. Similarly, Aximp uses the System.Windows.Forms.AxHost class in the .NET Framework to wrap an ActiveX control.
The .NET Framework classes provide some very distinct and useful improvements in programming capability. In J#, every class derives from a single base class named System.Object. J# treats System.Object like java.lang.Object and maps the functionality to make any differences transparent. This support makes it possible to pass to System.Object and vice versa for assignments, parameter passing, and other usages. The same mapping is true for java.lang.String and System.String. You can use collection classes, such as System.Collections.ArrayList to store a group of elements of varying type by simply copying them into an ArrayList object. The .NET Framework CLR automatically converts these to System.Object references while maintaining all of the underlying public fields, public methods, private fields, and private methods, although these may differ among all of the elements stored in the ArrayList object. After recall from the ArrayList object, the J# application can simply cast the object back to the proper class and utilize all of the fields and methods.
After reviewing all this analysis of the similarities and differences between J++/WFC and J#, a number of important conclusions indicate there are strong benefits to transitioning from WFC to .NET Framework programming.
- Short learning curve due to similarity of characteristics and programming approach.
While some of the assembly names have changed, major features such as forms and events are implemented and behave in J# the same as their counterparts in J++/WFC. After a short time to learn the assembly context names, a WFC programmer is likely to become immediately productive using .NET Framework classes. Many of the important features for programming, such as reuse of ActiveX controls and access to the native Win32 API, have also been preserved in almost the exact same form.
- Richness of the evolved library and utility of features such as System.object lead to greater productivity.
Extensive effort was exerted during.NET Framework development to insure that the .NET Framework classes are powerful, flexible, and easier to use than the WFC implementation. A really powerful example of this utility is the combination of the ArrayList class with the object base class.
- Reuse of existing components in Java and other languages through wrappers shortens time to deliver an application to market.
Transitioning from J++/WFC to J#/.NET Framework classes for new efforts does not require that you abandon previous components that you have developed. Nor will you have to avoid using other commercially available components. The wrapper class and appropriate class generation tools are available and integrated into Visual J# .NET.
- Easier transitions among programming languages makes programmers more productive.
By using the .NET Framework classes as the basis for applications in J#, programmers will be more easily able to program or to understand code written in the variety of .NET Framework-capable languages. This benefit results from the unification offered by the .NET Framework classes. Rather than offering a separate set of libraries and runtimes for the C++ programmer (ATL / MFC), the J++ programmer (WFC), and the Visual Basic programmer, all languages now exist "under one roof" and can benefit from the concerted development efforts and customer feedback that Microsoft has used in building the .NET Framework. As the .NET Framework evolves and new versions are introduced, this synergy will remain. Developers are also better equipped to transition from one language to another if they so choose, since the differences between a J# and a Visual Basic .NET program are purely syntactical and rely on the same overlying architecture. Similarly, developers of any .NET Framework language are free to build applications for any scenario: a developer who uses Windows Forms one day will have a very easy time building the ASP.NET Web Forms version of the application the next day given the similarities in the class architectures.
- New components written explicitly for .NET in C# and Visual Basic .NET can be reused.
A large number of components are being written in various .NET Framework compliant languages. These components provide applications with a huge number of really spectacular features that utilize the enhanced capabilities of the .NET Framework classes. By transitioning new development efforts from J++/WFC to J#/.NET Framework classes, J# components and applications will be able to take advantage of these new components with no additional integration efforts. This allows new J# programs to provide all sorts of exciting features and capabilities in a shorter development time than would be available using J++/WFC.
If you are starting a new development project, you should seriously consider transitioning from J++/WFC to J#/.NET Framework classes. The shorter time to market that will result from using the .NET Framework classes will more than compensate for the small amount of time necessary to learn to use the .NET Framework classes from within a J# application. Actual migration strategies are beyond the scope of this article, and vary greatly from application to application, but a good resource is the Visual J# .NET newsgroup at Microsoft.Public.Dotnet.Vjsharp. The Visual J# .NET product team is regularly engaged in that newsgroup, as are many other professional J# developers, so it's a great place to find answers.