Cover Story (sidebar) / May 1998

Calling Native Code

Tom R. Halfhill

Some say it's cheating. Others say it breaks the promise of write once, run anywhere. Could it even be a Communist conspiracy?

Nope, it's a native method call — a controversial technique for squeezing more performance out of Java. Java applets normally can't do it, because Web browsers have a security manager that prevents hostile applets from doing evil things to your system. But stand-alone Java applications can do virtually anything native applications can do, and that includes calling native executable files such as DLLs and OS services.

Critics say it threatens Java's integrity. Perhaps they don't realize Java has always allowed it. Java has a built-in keyword (native) that declares a Java method as the gateway to a native binary. Java Development Kit (JDK) 1.1 defines a native interface called native method invocations (NMIs), and JDK 1.2 will introduce a better one called the Java native interface (JNI).

NMIs neatly partition a Java program into platform-dependent and platform-independent modules. As Java gets faster, developers can rewrite the native modules until eventually the whole application is pure Java. That's the vision.

Native methods are also a good way to integrate Java programs with existing systems -- a big point for businesses that have lots of legacy software. And they can tap the richer veins of native APIs.

Microsoft's Visual J++ supports a Windows-specific interface called J/Direct. With J/Direct, a programmer merely precedes a Java native method declaration with a compiler directive that identifies a DLL by its filename. The Java native method passes any parameters that the DLL function requires, and it receives any results the function returns.

J/Direct is easy, but Microsoft isn't finished. In March, it planned to introduce the Windows Foundation Classes (WFC) for Java. This is a library of Java classes that wrap major parts of the Windows API in Java code that handles native method calls automatically.

Let's say you want to create a push button. Normally, you'd call the Button class in Java's Abstract Window Toolkit (AWT), a class library that maps cross-platform GUI components to native components.

Microsoft's WFC bypasses the AWT. WFC's Button class has a constructor that uses J/Direct to invoke the button function in USER32.DLL, a standard Windows library that has basic GUI components.

According to Microsoft's informal tests, a WFC window with 12 miscellaneous components opens and closes about 600 percent faster than an identical AWT window. Line drawing is about 50 percent faster. Filling a list box with 2000 strings is about 12 times faster.

What's equally important is that the WFC gives Visual J++ programmers access to almost the entire Windows API. They can call functions that Java APIs don't duplicate: Multiple Document Interface (MDI) windows, graphics, animation, rich text objects -- the works.

"We're always going to be able to give the developer full functionality," says Bill Dunlap, Visual J++ product manager.

Of course, the resulting programs run only on Windows. That fits Microsoft's business strategy of promoting Java as a language, not as a virtual platform. But J/Direct and the WFC do offer a way to get higher performance and richer functionality.

Windows Foundation Classes vs. Abstract Window Toolkit

Diagram of
                  difference between WFC and AWT.
Microsoft's Windows Foundation Classes are faster than Sun's Abstract Window Toolkit, but they run only on Windows.

Copyright © 1994-1998 BYTE

Return to Tom's BYTE index page