WFC is a large library of Java classes-much too large for us to cover in one chapter. In fact, investigating the classes that make up WFC will consume all of Part II and much of the remainder of this tutorial. In this chapter, we'll discuss one package of classes-the file input/output (I/O) package com.ms.wfc.io. From this discussion, you will get a basic knowledge of how WFC works. You will be able to use this information when we investigate windowed apps in .

Organization of WFC

WFC is organized into a series of packages as follows:

Package Package description
com.ms.wfc.app Provides classes that encapsulate Windows app operations such as threads, messaging, and access to the Clipboard and the Windows registry.
com.ms.wfc.core Used by the Java development tools. Most of these classes are not used directly by the programmer.
com.ms.wfc.data Provides access to data stored in databases by means of ActiveX Data Objects (ADO).
com.ms.wfc.html Provides classes for accessing Dynamic HTML. This is the only WFC package that is devoted to applet development.
com.ms.wfc.io Includes the classes that perform file input/output (I/O). This package is presented in this chapter.
com.ms.wfc.ui Provides the WFC user interface for Windows apps.
com.ms.wfc.util A catchall package of unrelated utility classes.

The com in the package name indicates that a package isn't intrinsic to Java. The rules of Java require this prefix to avoid name collisions with packages provided by other companies. The ms presumably stands for Microsoft. Thus, the full name of the File class within the WFC io package is com.ms.wfc.io.File.

NOTE
Don't panic; the import statement makes using the prefix optional, as you will see in the examples later in this chapter.

Why WFC?

Before we talk about how to write WFC-based apps, I think I should answer the question, "Why?" This is really two questions in one: "Why create Windows-specific Java apps?" and "Why use WFC?"

In answer to the first question, once an app has been compiled into an executable, it is automatically specific to the operating system for which it was compiled. Thus, to say that your .EXE file is limited to running under Windows isn't a limitation at all. True, you can deploy Java programs as .class files, but for apps the prospect of forcing the user to supply JVIEW or an equivalent Java app viewer doesn't seem practical. The point is that you can recompile source code that uses the generic Java library functions to run under any operating system. However, using WFC limits your apps to run under only Microsoft Windows. You must decide whether this is a limitation that you can live with.

I should point out that you would be limiting yourself to about 95 percent of all of the desktop machines in the market. In addition, if Microsoft Windows is your only operating system and you're writing an app for your own use, this is no limitation at all.

To offset this restriction of using WFC, you would expect to receive some benefits. Here we arrive at an answer to the second question above. The WFC package provides four distinct advantages to the Windows programmer:

Let's examine the first three assertions by looking at the WFC package ms.com.wfc.io. I'll spend the remainder of the tutorial demonstrating the development tools.