What is the difference between JFC & WFC?

Jeff Mackay

JFC supports robust and portable user interfaces. The Swing classes are robust, compatible with AWT, and provide you with a great deal of control over a user interface. Since source code is available, it is relatively easy to extend the JFC to do exactly what you need it to do. But the number of third-party controls written for Swing is still relatively small.

WFC runs only on the Windows (32-bit) user interface, and uses Microsoft extensions to Java for event handling and ActiveX integration. Because ActiveX components are available to WFC programs, there are theoretically more controls available for WFC than for JFC. In practice, however, most ActiveX vendors do not actively support WFC, so the number of controls available for WFC is probably smaller than for JFC. The WFC programming model is closely aligned with the Windows platform--it doesn't extend (or even interoperate with) AWT, so it feels more like programming with VB than with Java. Source code is not available, so you're on your own when extending the library.

In terms of functionality, WFC and JFC are similar: they both offer a similar range of controls, they both support clipboard and drag-n-drop operations, etc. WFC performance is better than JFC, and in general, memory requirements for WFC are lower than for JFC. For simple user interfaces, WFC is easy to develop with. For more complex user interfaces, WFC is more difficult than JFC. WFC was written with a component mindset: the details of any specific component are hidden within the component. JFC was written with an object-oriented mindset, providing a greater degree of control.

The bottom line is: If you need a robust, cross platform user interface, use JFC. If you're writing a quick and simple front-end, and if all of your clients are running Windows, and if you don't mind the Microsoft-specific extensions to Java, consider using WFC.