Microsoft Architect Speaks Out on WFCs for Java

Wednesday Mar 11th 1998 by Kieron Murphy
Share:

The Windows Foundation Classes are an application framework for Windows based on Microsoft Corp.'s J/Direct application programming interface technology. Their architect, Anders Hejlsberg, explains what developers can expect from them.

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.

USER:

Button button = new Button();
button.setText("OK");
button.setLocation(10, 10);
form.add(button);
DHTML:
DhButton button = new DhButton();
button.setText("OK");
button.setLocation(10, 10);
document.add(button);

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.).

WFC Event Model

Hejlsberg first contrasted the WFC Event model with that of the Java 1.1 AWT. He said the latter uses interfaces in which the event sink must implement the interface, requiring adapter classes, and it is limited to manual multicasting. By contrast, in the WFCs, the event sink just implements a method, requires no adapters, and it offers automatic multicasting, taking care of the "housekeeping" logic.

New to the Java lexicon, the WFCs employ what Microsoft calls "delegates." These are object-oriented function pointers, which rather than simply point to a function entry point, they point to objects and the entry points of methods, according to Hejlsberg.

The following examples are sample code for declaring, creating and invoking WFC delegates, as demonstrated by Hejlsberg.

To declare a single-cast delegate that takes two string arguments and returns an integer:

public delegate int Comparer(String s1, String s2);
To declare a multi-cast delegate that takes an Event object parameter:

public multicast delegate void EventHandler(Event e);
The latter then becomes:
public class EventHandler extends Multicast
{
        public EventHandler(...) {
        }

        public void invoke(Event e) {
        }
}
To create a delegate:
public class MyForm extends Form
{
    Button ok = new Button();

    public void initForm() {
        ok.setText("OK");
        ok.addOnClick(new EventHandler(this.okClick));
    }

    public void okClick(Object sender, Event e) {
        MessageBox.show("You pressed Ok.");
    }
}
To invoke a delegate:
public class Button extends Control
{
    EventHandler click;

    public void addOnClick(EventHandler value) {
        click = (EventHandler)Delegate.combine(click, value);
    }

    protected void onClick(Event e) {
        if (click != null) click.invoke(this, e);
    }
}
The following illustration demonstrates how delegates work in principle.

Figure 5. Delegates in action (courtesy of Microsoft Corp.).

Events and delegates can have two basic types of relationships, according to Hejlsberg. They can have a many-to-one relationship, in which multiple events can be mapped to the same event handler; or they can play a one-to-many role, in which multicasting enables multiple event sinks. Since delegates are objects, they can use lists, hash-tables and so forth for storage. And by using dynamic event routing, developers can add or remove event handlers at runtime.

Grab Bag of Features

The Microsoft architect also spoke of additional features to be found in the new foundation classes. These include:
  • stateless components, which can modify any property at any time and in any order, as well as provide on-demand resource allocation and auto-recreation as needed
  • automated garbage collection, which eliminates resource leaks or invalid handles and enables developers to manually dispose of components
  • encapsulated native access, which enables access to underlying platform resources and which employs J/Direct or COM to allow access to any API
  • GDI encapsulation, which consists of a graphics class, GDI objects and image classes
  • resources and localization, in which properties can be marked localizable and a ResourceManager class and Locale class are available
  • And miscellaneous "other goodies" such as an ArraySorter and StringSorter.

Key Words in Debate

In response to numerous press accounts in recent days focusing on new "key words" being added to Java in the WFCs, Hejlsberg said that the reports must be referring to the use of "delegate" and "multicast." These features are only "extensions" to Sun Microsystems' version of Java, according to Hejlsberg, which can be "switched off" by any user of the Windows Foundation Classes. (He also stated that two new key words will also make their entrance to Java terminology in the Visual J++ 6.0 compiler: "conditional compilation" and "conditional methods.")

He asserted that everything done with the WFCs is compatible with Microsoft's license with Sun to use Java.

Asked about the timing of today's announcement relevant to Sun's release last week of Version 1.1 of the Java Foundation Classes, Swing 1.0, the WFC architect said this was just a "pure coincidence." He claimed that he deliberately avoided looking at the Sun JFCs, so as not to compromise his own team's design efforts.

A spokesperson for the Java product development group at Microsoft said of the matter that Swing 1.0 is "analogous in functionality to the AFC class library" released last summer. "We then took AFC and tried building significant pieces of software with it and failed. AFC will continue to exist to allow customers to address the limited set of development issues that a diluted, lowest-common-denominator cross-platform set of class libraries can solve," said Jon Roskill, a Visual J++ product manager. "You can not compare JFC/Swing and WFC, they are like apples and oranges. The amount of functionality you get with WFC on Windows versus JFC/Swing is like comparing a Boeing 777 to a 1969 VW Beetle. We are having great success building commercial software in VJ/WFC, the VJ6 tool itself is a great example of this ... significant parts are built using WFC in itself."

Hejlsberg said that reaction from developers who had seen the WFCs demo'ed was "very positive." Roskill added that several tool vendors, including Sybase's Powersoft division and Metrowerks have already announced support for the WFC in their Java tools.

"I am sure others will follow," he said. "Beyond tool licensees we have had significant interest in the general third-party tools community."

Hejlsberg reiterated that the number-one goal for the WFCs is to offer developers the best and most pragmatic solutions to their coding needs. "We're solving problems here for people who want to build real-world applications quickly and run them on Windows."

A spokesperson for Sun, the creator of Java and the recently released Swing 1.0 set of Java Foundation Classes, told developer.com that the company was unfazed by the move by Microsoft. "The WFCs only run on Windows, so I don't see them as a threat to the JFCs at all -- the JFCs are cross-platform and secure," said Lisa Poulson, head of public relations at Sun's JavaSoft business unit. "If developers only want to write to Windows, they have lots of APIs and classes to use. More of the same isn't an issue for us."

Go to developer.com's discussion forums for more talk about WFCs.

Link on This Story:


About the Author

Kieron Murphy is the Editorial Manager of EarthWeb, in New York City.


Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved