MSDN Interview
March 11, 1998
When we wanted to learn about the new Windows Foundation Classes (WFC), we went straight to the source: chief architect Anders Hejlsberg.
The Windows Foundation Classes provide a new application framework that forms the foundation of the next version of Microsoft® Visual J++™. WFC gives developers a set of class libraries to build full-featured, native Windows® applications in Java.
In this interview by MSDN Online's John Swenson, Hejlsberg explains how and why his team built the Windows Foundation Classes.
MSDN: Why did you feel it was necessary to build the new Windows Foundation Classes?
Hejlsberg: There are many reasons. If you look at it from a Java perspective, Java class libraries suffer from what I call the least-common–denominator effect. They really basically only support UI metaphors that they can guarantee an implementation of across different platforms. This means no keyboard accelerators, no right-menu clicks, different threading semantics, and generally just a bunch of performance problems, because you are trying to present the world in a different model than what it really is.
It's very hard in Windows to change the Windows threading model, which is apartment-threaded, to a free-threaded world that characterizes AWT (Java's Abstract Windows Toolkit). The net result is that you end up with sort of a disconnected feeling, that your UI has a lot of flicker and bizarre repainting.
So that's one reason. Another is functionality. AWT is a very crude and very sparse UI library. All of the things we've become accustomed to in Windows like list views and tab controls and context menus and such are just plain missing in AWT, and we feel there's a need for those.
Performance was a big reason too. AWT looks and feels like AWT. It's immediately distinguishable as being sluggish and bizarre-looking, whereas a WFC app is literally indistinguishable from any other Windows application. There's no way you can tell that a WFC application is written in Java. WFC apps also run at the same speed and perform the same as an MFC or Visual Basic® app.
Finally, there's interoperability. AWT lives in its own little world and sees things in a particular way. For example, AWT has no data-binding model whatever. WFC supports ADO (ActiveX® Data Objects) as a data-binding model. This allows you to mix data-bound components with ActiveX controls, mix them on Web pages, mix them with Visual Basic applications, and more.
This is just one example of a whole bunch of technologies you can use once you make the choice to write for Windows.
MSDN: Is that a hard thing for most Java developers to accept?
Hejlsberg: For some, it will be. Some buy the cross-platform mantra, and some don't. I think the past year has been a big reality-check for a lot of Java developers. You see it in a lot of our statistics. The secure customer index for Java development tools is about as low as you can go now, meaning that people aren't really writing and deploying enterprise applications in Java as much as some would like us all to think.
You see big companies like Corel canning WordPerfect Office for Java. You see Lotus eSuite getting totally negative reviews, saying basically this is WordPad functionality except it runs slower, takes up more disk space, and generally is less usable.
So there's a lot of reality that has set in over the last year. We've seen Sun tweak its message and start saying, "Well, Java really is not so great for the client. That isn't really what we were trying to, we were trying to do Java for the server."
MSDN: What is your vision behind this new WFC application framework?
Hejlsberg: There are actually many things. If I had to name the top three, I would say they are: First, a unification of Windows and HTML as UI metaphors. Second, building a component-oriented framework. Third, allowing you to write real-world Windows applications in Java.
Now let me try to talk a little about all of those.
HTML is great for a certain type of applications, and our traditional Windows model is great for another type of application, where you really have to get down and have direct access to the APIs (you're doing bit twiddling, animation, UI widgets, or whatever).
What we're doing is essentially putting a unified programming model on top of those two paradigms. So we have an encapsulation of GDI and all the Windows common controls … and we have an encapsulation of Dynamic HTML programming … all rolled into a set of Java objects that look and feel the same. They all share the same component model, the same types of properties, the same eventing model.
You can put code behind amalgams of HTML and Windows controls. But once you're in the code behind them, it's all the same space. The event handler that executes when you click a Dynamic HTML button is exactly the same as you can have when you do a menu pick, click a normal button, or whatever. That whole paradigm is very comfortable because it allows people to harness the power of the appropriate UI model, without having to learn a whole new way of programming.
MSDN: You're mentioning a lot of features focused on improved ease of use. Is it too hard to create applications today using Java?
Hejlsberg: Java has some very cool features. Java is a very nice, cleaned-up language, with a good balance between language features and a good balance between object-orientedness and built-in types.
Compare Java, for example, to Smalltalk, which also has garbage collection. In Smalltalk, everything is an object, and when you're adding two integers, you pay an enormous price. The designers of Java made a conscious choice that certain primitive types aren't objects. That's actually very meaningful. Java is a very nice marriage of classes and interfaces. Unfortunately, Java is accompanied by a lot of libraries that can be frustrating to use. In particular, the UI libraries.
To use this nice language with garbage collection and all these very attractive Java features, you have to trade off a whole bunch of other things. We're giving people a choice here. We're saying, "Java is a great language, but people want to be able to write applications for Windows and take advantage of the Windows infrastructure."
MSDN: You used the term Java objects. Can you explain what you mean by that?
Hejlsberg: I guess I meant Java classes. But there is actually a component model in WFC. You can take a Java class and add some meta-information to what we call a ClassInfo that describes its properties, methods, and events. Then you can install it on the tool palette in Visual J++. Drag it onto a form either as a visual or a nonvisual component, and manipulate it in the design-time environment.
You can also do that with ActiveX controls. You can import ActiveX controls (into the next version of Visual J++) and you can export ActiveX controls. So you can make these things look like ActiveX controls if you want to, and vice versa.
There's been all this talk (among some developers) about how HTML is going to totally replace any known UI metaphor. The other developer camp says, "No, we like writing traditional applications the way that we do them now."
In reality, there are good reasons why both methods can be employed. The thing that's really interesting is unifying them. The unification really is driven home when you put a common component model on top of the two paradigms.
Whether a developer is looking at properties of an HTML element or user element, they look the same to him. He writes an event handler in the same way. He can dynamically create new elements and put them into the HTML page, so the windows form in the same way.
The leveraging part is what's interesting here—getting you there quicker. You learn one model, you understand the other.
MSDN: Aren't some developers going to scoff and say, "Dynamic HTML is primarily just for Web pages, why would I use that in my Windows application?"
Hejlsberg: Some may. But I actually think Dynamic HTML is a great layout metaphor, even in traditional apps. Look at things like building help into your applications, building wizards, building dynamic reports in financial applications.
There are so many things that HTML is a better presentation paradigm for than our traditional forms. So I don't think HTML is just for Web developers, but on the other hand, I don't think (HTML and Dynamic HTML) are going to replace every application that was written using the traditional paradigm. I think there's a very interesting space in between.
MSDN: Did Microsoft use WFC to write parts of the next version of Visual J++?
Hejlsberg: Yes, the forms designer is all written in WFC and Java, so is our property inspector, and so is our two-way code parser/code generator that underlies the forms designer. There's a huge amount of code written using WFC and Java in our property editors, customizers, and property pages.
We are not trying to hide from the world that this is Windows. We actually have the ability to easily interoperate—either through COM or just through straight APIs and J/Direct™—with the shell, and host all of these components in the Visual J++ environment.
WFC is a very productive tool. We started this development effort just six months ago. Six months ago there was nothing, so we've come quite a long way in a short time. It's been quite remarkable.
MSDN: Can you explain the design hierarchy of WFC and the design choices you had to make when creating this new technology?
Hejlsberg: If you look at the hierarchy, basically there are a bunch of visual and nonvisual elements and components in there. One of the first choices we had to make there was separating "componentness" from being a control that goes on a form, such that you can have nonvisual controls or different types of visual controls.
For example, in WFC, all of the user controls are essentially encapsulations of an HWND (a window handle). But there are also all of the Dynamic HTML elements that are encapsulations of UI elements on an HTML page. They're visual in completely different ways, but they all inherit from a base component that gives them "componentness," that gives them properties, methods, and events and the ability to describe metadata.
So that was definitely one of the design choices that impacted WFC. Another was allowing developers to dynamically create components at run time. Certain design-time environments allow you to do certain things at design time and then give you different characteristics at run time. When you're building a form, there are certain things you can do, like create components. But then at run time you may not be able to create new components.
We took the tack that anything you do visually you can also do with code, and indeed, the forms designer also writes code. It's a convenient way of writing code, and you actually learn from the code when you look at it. So that was another important design factor.
Another factor was our thinking about concepts like delegation versus subclassing. WFC essentially allows you to use components in two important and distinctly different ways. When you work with the visual designer (in Visual J++), you're doing composition of forms, you're putting new components within other components. You're essentially compositing new UI. That's one way of building apps with WFC, and it is very similar to Visual Basic, for example.
Another way is to use subclassing, where you take an existing component and you derive from it and override virtual methods. That's the object-oriented aspect that enters in. This is the model used by Visual C++® and MFC.
We built a framework that supports both metaphors. That causes you to make a bunch of interesting design decisions, in order to make sure you don't favor one type of customer or one type of use over another.
Finally, another factor that impacted our design of WFC was things like logical versus physical containment, where some component models will essentially define containment as controls being put within other controls. That's your programming name space—your visual nesting names. We've distinctly unmarried the two, such that components can physically be contained within each other. But there's also the notion of logical containment, which is all of the components that you can put on a form, and that you write code behind, so to speak.
In the logical containment world, things are only required to be components, not controls. Second, they are all at the same containment level. It's important to make that mental distinction up front when you design a robust component model, so it isn't just married to one UI metaphor.
MSDN: How does WFC relate to the next version of Visual J++? Will it be part of Visual J++?
Hejlsberg: Yes, the two are a package. It's the symbiosis between WFC and Visual J++ that makes the sum greater than the parts. There's a framework underneath them that allows you to do MFC-style programming, where you do subclassing and whatever. And there's a visual designer that lets you do Visual Basic-style programming. So you get Visual Basic ease of use with the expressiveness of C++. That's how I try to characterize it.
The thing that's very interesting is how we designed the framework alongside the designer that will be used for the framework. I believe fundamentally that this is the only way you can validate a component model.
If you look closely at JavaBeans, it's rather evident that Sun defined a component model, but they weren't building a design tool alongside it. Other companies were building design tools (for JavaBeans), but the communication channel has lower bandwidth than you get by building the two in unison. The net results reflect that.
There are some interesting disconnects when it comes to JavaBeans. For example, Sun's intended persistence model for JavaBeans is serialization, where you essentially file out all of the components as binary images and then reconstruct them at run time.
But all of the major design tools for JavaBeans, like JBuilder and Symantec's Visual Café, generate code. They don't use serialization, because serialization has nasty versioning problems. But JavaBeans was written with serialization in mind, so when you go to write code there are all sorts of things you cannot learn about components, such as default values of properties, just to name one example. It makes it a lot harder to do code generation.
These are interesting things that you don't see as a reader of all the (Java) hype. But when you actually try to build something, you run your head right into them.
MSDN: What are the high-level objects provided in WFC and the next version of Visual J++?
Hejlsberg: There are, of course, lots of UI controls—a full-fledged UI library. There are also a lot of HTML elements. They are in two branches of the inheritance tree—one branch deals with Windows and the other branch deals with HTML.
Then we have file I/O classes and utility classes such as lists and hash tables, classes that deal with resources, and classes that deal with localization. We have a very good localization story. There's also a GDI encapsulation, where you have a graphics object and pens and fonts and brushes. This is a much more full-fledged drawing model than what AWT presents today. Those are some of the high-level classes (in WFC).
MSDN: Can you describe the new eventing model in WFC, which uses something you call delegates?
Hejlsberg: The technically correct term for delegates is "bound method references." If you think about the ActiveX or JavaBeans eventing models, they both use interfaces for eventing. We use delegates, or bound method references.
For example, in the ActiveX or JavaBeans world, if you have a button that wants to fire an event, it does so by defining an interface. Someone has to implement that interface and then give it to the button so the button can call back on that interface, in order to fire events.
In the WFC component model, a button essentially has a bound method reference that it calls when you click on the button. You don't have to implement an interface in order to receive the event. You simply have to supply an object and a method and say to the button, "When you're clicked, just call this method on this object." So it's a simpler model. It's also a more flexible model.
If you look at how JavaBeans tools today implement eventing, they have a problem. Let's say you have a form that has 100 buttons on it, and you want to have a separate event handler for each button. Now you need to implement this event interface 100 times, but you can't, you can only implement that interface once.
You're faced with either having to write 100 adapter classes—that is, little classes that each implement the button interface and then forward it to the particular event handler—or you have to write one handler that has a gigantic switch statement that switches on the sender of the event.
You're either trading a lot of space away, because classes are fairly big in footprint, or you're trading speed away. But with the WFC delegate model, you're not trading anything away.
The other thing that's interesting about delegates—and particularly how we implemented delegates—is that we can do automatic multicasting of events. A control that fires an event sees essentially one bound method reference, one delegate that it calls to. That delegate will (underneath the hood) potentially call many receivers of the event. This all happens automatically, and with great efficiency.
Another thing that's interesting about delegates is they allow you to do many-to-one mapping of event handlers. Because you're just referencing methods, you can have a button click and a menu click both go to the same event handler. You don't have to write these things that forward the call to a common routine.
Finally, the thing that's interesting about delegates is that they make it very easy to do dynamic routing of events. This is particularly interesting when you're doing data-driven instantiation of forms, where you read the database, figure out what fields you want to present, and then dynamically instantiate a bunch of edit controls or whatever. Then you bind their events so you can update the data that underlies them.
Our delegate-based eventing model makes it very easy to do this. It's as easy to attach an event handler to a UI control as it is to modify a property. So there are many interesting advantages to delegates.
MSDN: I haven't heard you mention COM much. Is COM an important part of the next version of Visual J++?
Hejlsberg: Absolutely. COM is crucial to importing and exporting ActiveX controls. It's also important to interoperating with COM servers and COM programming models such as ADO, for data binding. COM is also essential for interoperating with MTS (Microsoft Transaction Server) to provide server-side objects.
COM essentially is our gateway to the outside world, the world outside the Java VM. COM and J/Direct are the means whereby Java accesses all the existing infrastructure of Windows. We would definitely not do well without COM.
MSDN: How will developers create components in WFC?
Hejlsberg: There are many ways. It sort of goes on a scale. To begin, developers just implement forms, composite them, and put code behind them. Since everything you write in WFC is inherently a component, you are in a sense writing a reusable component when you create a form, although it is extremely domain-specific.
The (Visual J++) IDE allows you to write users controls, which are almost like borderless or frameless forms. You know them from Visual Basic, where you composite and maybe do a bit of subclassing in there to tweak things, and maybe build a new control specific to your application.
The next step in creating WFC components is to take one of the controls in WFC, or even just a generic control, and through subclassing, implement a completely new control. This control could be specific to your app, or maybe you are writing it as a part of a more generic library of WFC controls.
Finally, you can also write ActiveX controls in WFC.
MSDN: Is there any advantage to creating ActiveX components in WFC?
Hejlsberg: Yes, there is. You can instantiate these components in the browser using a Java moniker. In other words, there is no need for client-side registration.
Another advantage to using WFC to create ActiveX controls is it lets you take advantage of subclassing. You can subclass existing controls and just tweak them a little bit, as opposed to starting entirely from scratch.
Controls created with WFC can also have better performance characteristics. One of the things that characterizes Java is that it has two worlds. You're either inside the Java VM (virtual machine) or you're outside the VM. You're either inside the garbage-collected world, or you live in the non-garbage–collected world. There is a fairly strong barrier between the two worlds.
The reason the barrier is there has to do with how the garbage collector works. You can't just freely hand objects out of the garbage-collected space to someone who isn't garbage collectable. The minute you hand the object out, there is a reference to it the garbage collector doesn't know about, and therefore can't track.
What has to happen whenever you hand things in and out of the (Java) box is that a marshalling layer needs to sit in between and basically "do the right thing." Primitive types go straight in and out of the box, but objects get artificial roots, so to speak, that allow the garbage collector to track what's happening to them.
These interoperability layers are done by J/Direct and our Java VM's COM interop. There's clearly a cost associated with using these layers, however. As long as you stay in the VM, you get higher performance than if you're making a lot of transitions in and out. So one advantage to ActiveX controls created in WFC is you get increased performance.
MSDN: Do WFC controls disappear after they're downloaded and used, similar to Java applets?
Hejlsberg: They can, if you choose. It depends how you use them. You can either have WFC controls behave essentially as applets, or you can put them in a CAB file and download the CAB, at which point you can grant them greater permissions.
You can also install WFC controls on a user's machine and, through the package manager, give the user greater control over updating WFC controls and let them manually get rid of controls.
The thing about Java applets is they are always nonpersistent. They never get cached. They immediately disappear and you have to download them every time. We give you a choice. You can either stay with that model (and create nonpersistent WFC controls), or download and store WFC controls on your machine.
MSDN: How can developers use Visual J++ to link applications to databases? With ADO?
Hejlsberg: Yes. For WFC, we decided to use the premier data-binding interface (ADO) that our other tools such as Visual Basic use. So binding to data in WFC is very similar to how you data bind in Visual Basic. You have recordsets and data sources. We also have a data binder object that allows you to bind a field or column to a particular property on a particular object, and everything just sort of happens automatically.
You can data bind to nonvisual things, too. In fact, you can data bind to methods on your own objects, which is pretty interesting.
MSDN: How do you balance ease of use and power in WFC?
Hejlsberg: One way is by making sure you can create components, set their properties, and add event handlers in a completely uniform way across the component. But you do not give up the ability to subclass, to get straight at the window handle and handle a window message, if that's what you want to do. So all the power is there, but it's taken to a higher level of simplicity.
WFC also lets you completely virtualize all window handle management. You never have to manually create anything, as you have to within Windows. There are no special semantics, such as you must set these parameters before the window handle is created, and you must set these other handles after the window handle is created, and once the handle is created you can't change the style or the UI element. In WFC, this is completely hidden from you.
WFC will manufacture the window handle or the underlying HTML element, if you're talking about Dynamic HTML. If you change something that requires a new handle to be fabricated, WFC will do that for you. But if you really want to get at the handle and call straight to the Windows APIs, you can do that as well. It's all about ease of use. That's really what WFC comes down to.
MSDN: Can developers use this technology to build server-side components?
Hejlsberg: Today, Visual J++ and our COM interoperability provide a great way of building server-side components*. You can build Java classes and turn them into COM components, and you can add NT Server transaction semantics to your components, supported by our VM. [Editor's Note The new version of Visual J++ will make it easier to build transaction-aware components for use with Microsoft Transaction Server. Microsoft is investigating whether to add new classes that encapsulate Microsoft Message Queuing (MSMQ) as well as Active Directory services (ADSI)].
The WFC framework also allows you to do server-side generated HTML, which is a really cool feature. The thing that's cool is it gives you the same programming model on the server as you have on the client.
On the server, you can create a document, create a table component, add some rows to the table, add the table to the document, and return the document, which then gets sent over as HTML. It's the same programming model on both client and server, which is really cool.
MSDN: Final question. Did you think much about the politics of Java when you were designing WFC?
Hejlsberg: No. We were being very pragmatic about this whole issue. Yes, there's politics and then there's reality. I've got to write this app and it's got to run on a Windows machine. There's all this Windows infrastructure I want to take advantage of, be it on the server side or the client side. That's the market we designed WFC for.
Comments? Send us e-mail.
Hejlsberg joined Microsoft a year and a half ago, following a 15-year career at Borland International, where he was chief architect of Delphi, Turbo Pascal, and other tools. Before moving to California and becoming one of Borland's original employees, he learned how to develop software in his native Denmark.