January 17, 2021
Hot Topics:

Microsoft Architect Speaks Out on WFCs for Java

  • By Kieron Murphy
  • Send Email »
  • More Articles »

Microsoft today announced the roll-out of the new feature set to the Visual J++ 6.0 Technology Preview. The designer of its new Windows Foundation Classes spoke with developer.com just prior to the announcement.

The WFCs are an application framework for Windows based on Microsoft Corp.'s J/Direct application programming interface (API) technology. They consist of a set of object-based class libraries written in Java that will enable developers to write applications optimized for the various Windows platforms.

Anders Hejlsberg, the architect in charge of the WFCs at Microsoft Corp.'s developer tools division, said the nascent tool set offered developers creating graphical user interfaces for Java apps running on Windows platforms three major design improvements: unification of USER/GDI and DHTML; a component-oriented framework; and the opportunity to create "real Windows applications" using Java. All without changing the regulation Java bytecode.

"The WFC basically allows you to leverage Java the language and Windows the platform," said Hejlsberg.

GUI Unification

Hejlsberg said developers should be able to use the Dynamic Hypertext Markup Language (DHTML) along with Windows' USER Dynamic Link Libraries (DLLs) and the Graphics Design Interface (GDI) to "mix and match" a common component model in the same GUI application. By using the WFCs, he said, it would be easy for developers to "put code behind HTML pages using Java in essentially the same fashion that you put code behind forms in products like Visual Basic or Delphi." He offered the following code samples to illustrate the point.


Button button = new Button();
button.setLocation(10, 10);
DhButton button = new DhButton();
button.setLocation(10, 10);

Component-oriented Framework

The driving force behind Delphi when he worked for Borland International, Hejlsberg said there are two halves to the component-oriented framework of the WFCs.

The component-oriented part employs metaphors such as composition and delegation to offer the comfort of a rapid application development (RAD) environment, much like Visual Basic. The framework part uses metaphors such as subclassing and overriding which, Microsoft claims, deliver more power and expressiveness, as in the Microsoft Foundation Classes (MFC) model. The WFCs unite both halves, according to Hejlsberg.

"With the Windows Foundation Classes, we do a lot of simplifying of the programming model, but we don't try to gratuitously change the underlying concepts," said Hejlsberg. "You don't have to do a lot of the housekeeping you normally do when you allocate objects and have to select them into context and remember to delete them. All of that stuff is automatically taken care of."

Windows Applications in Java

Hejlsberg said, "Java has suffered from this least-common-denominator syndrome, where because certain UI aspects weren't supported on a particular platform, they were just left out of the UI libraries." He said a central design goal for the new foundation classes is to let developers write Java applications for Windows that "look and feel" like other native Windows applications. Moreover, apps using the WFC offer enhanced performance, more-robust databinding and interoperability with Windows-based distributed object computing models such as COM/DCOM, he added.

The WFCs extend Java's APIs with a set of new packages:

  • wfc.core for the core classes
  • wfc.app for the application model
  • wfc.ui for the user interface elements
  • wfc.html for DHTML support
  • wfc.data for database access
  • wfc.io for file and stream I/O
  • wfc.util for the utility classes
  • wfc.win32 for the Windows APIs
The following illustration, provided by Microsoft, depicts the overall WFC architecture.

Figure 1. The WFC architecture (courtesy of Microsoft Corp.).

"You essentially now have the same, familiar programming model whether you are building a standalone app that doesn't use HTML or you are putting code behind an HTML page or you are building a composite application that uses aspects of both," said Hejlsberg. "For example, what's really interesting is that the wfc.html package can operate either on the client or on the server with the identical programming model. So you have complete parallelism in programming models between server and client. This is really powerful stuff." The WFC class hierarchy can be illustrated as follows.

Figure 2. WFC class hierarchy (courtesy of Microsoft Corp.).

WFC Component Model

The WFC architect said that it is at the component level "where things start being very different" from the way they are in Java's Abstract Windowing Toolkit (AWT).

"First of all, a component is just that," said Hejlsberg. "It doesn't imply anything about being a visual thing. In the AWT, the root component is also an area on the screen, which doesn't really make sense when you're talking about non-visual components, such as a database connection or a timer. Things that don't have any UI can still be components in this class hierarchy."

In the WFCs, all controls and all DHTML elements are descendants of components. Conversely, WFC components typically extend base classes.

A WFC component must implement the standard interface, called Icomponent, and must provide a default constructor, or one that takes no parameters, according to Hejlsberg. Developers must use the reflection pattern of 'getXXX()' and 'setXXX()' to set their properties. Similarly, the pattern 'addOnXXX()' and 'removeOnXXX' is employed for events. To provide metadata for a class, such as information on the properties and events, users must provide an inner, named class. "For example, if you had a component called 'myComponent', you would also have within in it a public, static, inner class called ClassInfo that provides the metadata."

When asked why a developer would prefer this methodology over using Java's built-in reflection method, Hejlsberg replied, "Because there are certain things you can't find through reflection, like what is the default value of a property, what is the description string you want to display when the user asks for help on this property." WFC components can be detected by placing them on the class path or into the package manager in the Visual J++ virtual machine. These components can also be displayed in a toolbox, dropped onto a form, and edited in the property browser.

WFC components can be automatically persisted to code, meaning that when a developer design forms the component contains the code that goes behind the forms. Hejlsberg said that this, again, is where the WFC model is "richer" than its counterpart in regular Java -- persistence in JavaBeans.

"The persistence model in Beans clearly was always intended to be serialization," said Hejlsberg. "Serialization has some pretty nasty versioning issues, in that they persist the names of private instant variables in your binaries, and should you ever change your mind as to how a component is implemented internally, you are pretty much out of luck."

At present, WFC components are not compatible with JavaBeans unless an ActiveX "gate" is employed.

Components and Containers

When a component is put into a container, the container "fabricates" a site for the component, according to Hejlsberg. The container then gives the component an interface called Isite.

"The notion is that for every component you have in a container, the container has a site associated with the component," said Hejlsberg. "And there's sort of a pointer going in either direction. So a component can go to its site and ask for services in a generic fashion, this is how extensibility and communication between a component and its container works."

The following illustrates how WFC components "talk to" their containers.

Figure 3. WFC components and containers (courtesy of Microsoft Corp.).

Below is the source code for a typical WFC component.

public class MyControl extends Control
    public MyControl() {
        // Initialization

    public String getCaption() {
        // Return caption property

    public void setCaption(String value) {
        // Set caption property

    protected void onPaint(Graphics g) {
        // Paint the control

    public class ClassInfo extends Control.ClassInfo
        public void getProperties(IProperties props) {
            // Return PropertyInfo objects
The following illustrates the life-cycle of a typical component.

Figure 4. Component life-cycle (courtesy of Microsoft Corp.).

Page 1 of 2

This article was originally published on March 11, 1998

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date