Java Security Continues To Be A Popular Place
With a certificate protocol, some Java applets and ActiveX components receive special privileges. For the corporate developer, this arrangement makes sense. You can design a system where certain applets perform file I/O, for instance. (In the case of importing a file, this ability allows a new Java-based system to mimic an older client-server application.) You might even consider caching data locally to improve performance.
As you might expect, Microsoft has been innovative in letting developers gain access to native or legacy code from within Java applets and ActiveX controls. These options usually involve making a choice, particularly with running Internet Explorer. (In the worst case, if it bothers you, it involves running a Win32 system of some sort.)
A reasonable counterargument, says Bob Haley, spokesman for US Netizen, is that corporate developers make such choices all the time. We invest in a technology infrastructure–hardware and software–and can actually define minimum requirements to run on an intranet, such as operating systems and browsers. Writing 100 percent pure Java–with no access to legacy code–is a fine ideal, but many of us have legacy systems to migrate to and maintain.
One of the niftiest tricks of Microsoft’s Java Virtual Machines (JVMs) (which can be disabled, of course), which are part of Internet Explorer or the stand-alone JDK 2.0 (still in beta), is their almost seamless support for ActiveX components. ActiveX components allow an organization to place chunks of legacy code in reusable components that can be called easily from within a Java applet. The bottom line is that Java hides much of the difficulty of ActiveX programming, such as resource allocation, from the developer. You can use ActiveX components just as if they were Java applets, almost without thinking about them. The only worry is that you need to provide signed CAB files–the means of distribution for ActiveX components–during download and installation. The user must also select a security level within a browser to permit file I/O for trusted apps to take place.
Natives get Restless
Because they are written in native code and tailored to a specific operating system, ActiveX components have few restrictions. Once you hook into an ActiveX component in Java, you can make system calls or use C++ class libraries such as MFC. This COM technology is clearly vital to Microsoft’s other advanced Java technologies.
DirectX and Direct3D are now accessible through ActiveX/COM interfaces in Java. Once again, programming with these technologies in Java is actually easier than with C++, since some of the overhead of working with COM is taken care of for you through Java.
You don’t have to use ActiveX to get at traditional native-code perks such as performance and multimedia, however. The latest offering by Microsoft is J/Direct. J/Direct allows developers to access a wide range of Win32 C API calls from within Java applets. More than ever, it’s a clear signal that Java and the native Win32 operating system can coexist.
The point is, of course, not to encourage developers to use Win32 calls extensively, but to give them the option to optimize code with Win32 where it makes sense. For certain kinds of programs, such as the Windows multimedia system for playing WAV files, J/Direct gives developers exciting new possibilities. You can also read and write local files–carefully, of course–or access any of several hundred Win32 API calls to do work at the operating-system level with the promise of better performance.
A Direct Shot
The principle for J/Direct is remarkably simple. J/Direct allows Internet Explorer 4.0 JVM (preview release 2 or later) or programs written with Microsoft’s JDK 2.0 to access functions within the standard Windows dynamic linked libraries (DLLs). This means that any functionality already inside a Windows DLL can now be brought to your Java applets or applications.
The Java package or library of trusted classes are the ms.com. win32.* classes. (The class files and Java source files that power J/Direct are installed on your local machine.) This group of more than 100 Java files contains much of the standard Win32 API. Included here are the constants required by Windows as well as many structures and sections of the API that you need, you’ll see your Java applets perform better. It would be a big mistake to import everything, as that would slow down the compilation process at runtime.
Since the mechanism of J/Direct is so simple, it can be extended to include your custom Windows DLLs. You just need to write the “glue,” or stub, calls that define where your code resides. So if a programming shop had a library of souped-up graphics or statistical functions, it could be put into Java very quickly using J/Direct. Sure, you probably don’t want a lot of native code in the brave new world of Java. But it’s good to know that if you absolutely need to access the powers of the Win32 operating system, you can.
This month’s sample code includes two solutions to secure file I/O within a Java applet. (The files are available in the JavaImport.ZIP file, which accompanies this month’s column.) The first method uses an ActiveX control (named ProductImporter.OCX) to handle the file I/O for importing a CSV file into a Java applet. The data here isn’t so glamorous–a no-frills product list, manufacturers, part numbers and prices, and the like. The data is read from a local file using ActiveX and then parsed and displayed using Java. This ActiveX solution appears in the ImportFileOCXDemo.html page, and the JavaProdlistDemo.java file contains the real Java code behind this sample page. The demo shows the magic of ActiveX’s compatibility and ways to get around the limits of the Java sandbox carefully and securely. (Note that with this demo, the ProductImporter.OCX control resides within the same Web page and is scripted, in effect, using the Java applet.)
A second solution shows off the more direct capabilities of J/Direct technology. With this solution, the Java applet performs its own file I/O easily by invoking standard Windows calls to open, read, and close a file. (To keep things simple here, we’re using the –lopen(), –lread(), and related Win32 calls.) The JDirectImport.html sample page shows this approach at work. The entire importer demo can work within a single applet (with source code in JDirectProdlistDemo.java). When it’s time to accomplish the work of importing, you can do so within the Win32 idiom. The J/Direct layer does convert variables from the Win32 API to standard Java data types.
One comparison to make here is with Netscape’s plug-in model, where you can also have legacy C/C++ code call and be called by Java. But J/Direct is much less complex, mostly because you don’t have to leave Java in the first place, and because you can call specific Win32 API calls without committing to a different programming model. In the JDirectImport.java example, there’s no need to build a second component. But J/Direct is certainly not an excuse to skip designing a library of smart, reusable objects, whether in Java or ActiveX. J/Direct does open up options for better performance and the basic operations–principally, file I/O–that developers have traditionally expected in their programming environments.
With emerging technologies like J/Direct, the world of Java programming becomes more powerful. So instead of being mortal enemies, Java and Windows are becoming quite complementary, each enriching the other. Java is a smooth path to advanced Windows technologies such as Direct3D. And with J/Direct, Java offers a way to preserve standard Win32 APIs and the legacy code in DLLs. If your users demand strict allegiance to a pure Java credo, and you’re running on a variety of operating systems and browsers, then by all means give them what they want.