HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

The Microsoft Java tools are put down by some for lacking JFC, security and portability. I'll examine each of these in turn, but first a bit of context. For some time, C++ and Visual Basic have been the application development leaders. Now, rather suddenly, all developers are looking at Java as an interesting alternative. Java offers many critical benefits, but it lacks the low-level power of C++ and it generally won't be as fast. Most developers will never be able to reap its benefits if these significant detractions remain. The business opportunity is enormous for anyone shrewd enough to create Java tools that help developers reach the full potential of client machines. Microsoft knows this.

I have to laugh as I wade through the JFC vs. AFC debate raging in comp.lang.java Some Pure Javans despise Microsoft because Internet Explorer will ship with Microsoft's AFC instead of Sun's JFC. Isn't it really odd to hear people whine about what comes with a free product? Ultimately, it's in everyone's best interest if the two class libraries compete. You know, let the marketplace decide.

Some folks in the news groups don't realize that IE is completely capable of running JFC. If it couldn't, it would cease to be a competitive browser. In fact, JFC is downloaded automatically when an IE user browses a Web site that uses JFC. The surprise is that if Microsoft actually did ship JFC with IE, most users would still download JFC just one time! (As part of the IE download itself. Isn't the Web great?)

Critics charge that the capability of Microsoft's Java products to run ActiveX components outside of the Java sandbox is a security flaw. But Java vs. ActiveX should not be an either/or debate. For clever developers, the question is how much of each? ActiveX is a necessary means to take advantage of native-code modules when it is unsatisfactory to rely exclusively on the lowest common denominator of portable Java and HTML. While the browser sandbox presumes to secure Java code, keep in mind that all software, not just ActiveX components, but even shrink-wrapped applications and shareware downloads should be considered suspect. As a matter of fact, thanks to digital signature technology such as Authenticode, downloading native code over the Web will prove to be the safest method.

If you find that hard to believe, imagine this. It wouldn't be impossible for a rogue employee at a computer store to slip a virus into a box and reapply new shrink-wrap. Or a rogue employee at the ISP or the phone company could slip a virus into the bitstream of a downloaded piece of shareware. While those events are extremely unlikely, the point is that ActiveX and Java provide new tools to deliver software more safely. Although the average Internet user is at greater risk today than they were when the Web consisted entirely of static HTML, that goes hand in hand with us asking for Web pages that do more than just sit there. Now we can run rich Java and ActiveX applications over the Net without having to drive to the computer store.

Some argue that ActiveX and J/Direct not only make Java less secure, but also less portable. They say Microsoft is attempting to subvert the Internet from trying to standardize on Pure Java. Give me a break! For those who haven't noticed, Visual J++ compiles Pure Java code faster than anything; Internet Explorer is the fastest Pure Java Virtual Machine; and AFC is written entirely in Pure Java. Obviously, Pure Java is a great thing - when we can do it. But just as there are few great programs written entirely in ANSI C, Java programmers will often need to tap into the machine or the OS directly. ActiveX is a very useful means to do this.

ActiveX runs on most clients that connect to the Internet, including Macintosh, Windows and soon, several flavors of Unix. But even if ActiveX only ran on Windows, somehow the notion of giving more power to the 5 million Windows programmers who write code for the 100 million Windows users seems to be too complicated for some Pure Javans to comprehend. Portability is rightfully a key issue for Unix Java programmers because ignoring the OS and GUI differences between vendors would perilously restrict their market, which is already limited to about 1 million copies per year. But Windows developers like me already know our target platform. When Java is the right business strategy, we should not ignore our target platform to build needlessly portable and less powerful applications.

It's quite simple really. If Pure Javans don't like J/Direct or ActiveX, they don't have to use it. But if those of us who build rich Wintel binaries need a clean object-oriented, multi-threaded, net-enabled language with ActiveX and Win32, guess what? Now we have another great choice. Sometimes we feel like a sandbox, sometimes we don't.

About the Author
Scott Zimmerman has programmed for 17 years in over two dozen languages. He is Manager of Product Architecture with Azron, Inc in San Diego. Azron produces an award-winning wireless electronic medical record system for Windows NT. The opinions expressed here do not necessarily reflect those of his employer.

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.