“Pitfalls” article receives attention from JavaWorld readers

John,

This is hard to believe — or maybe not so hard to believe. This article is an advocacy piece masquerading as journalism. Who is the Deep Throat for this from Sun? By the way where does JavaWorld get its funding?

Stephen Vago

Stephen, Actually, if you read the author’s bio at the bottom of the article you’d realize John Zukowski is not writing for Sun, but for himself, a proficient Java developer and author of numerous Java books and articles. His perspective largely mirrors that of JavaWorld readers as a whole. JavaWorld is published by Web Publishing Inc., the online publishing unit of International Data Group — the world’s leading publisher of computer trade magazines. Sister publications include PC World, ComputerWorld, InfoWorld, and NetworkWorld. Like all IDG pubs, JavaWorld adheres to high editorial standards. In fact, the Computer Press Association honored JavaWorld as one of only three finalists in the Best New Publication (of any kind — print, online, broadcast) category of the annual Computer Press Awards. Like nearly all computer trade magazines, JavaWorld relies on advertising revenue. A quick look at our advertising base reveals that Sun spends relatively little on JavaWorld ads. If any single vendor can be singled out as our primary fund-provider, it is Microsoft, one of our biggest advertisers. Michael O’Connell

Editor-in-Chief

JavaWorld

Stephen Vago replies:

I didn’t assume at all that the author worked for Sun. However he seems to have knowledge of details of the Java compliance suite, which Sun has heretofore not made public.

The question about funding is not triggered by just this one article but about the overall coverage of Java issues by your magazine. Obviously, I subscribe and find it of great value as a Java developer (one who owns and professionally uses both Symantec Cafe and Visual J++). But almost all coverage seems to hold the view of Java that is advanced by Sun. I don’t recall a single article that ever criticized anything Sun has done with Java, either from a technical perspective or from a competitive perspective. If you can refer me to one or more such articles then I will gladly rethink my position.

Stephen Vago

John Zukowski responds: Stephen, The article you responded to is based on information made public from the press teleconference on October 7, 1997. (See https://java.sun.com/pr/1997/oct/transcript.html for a transcript.) I haven’t seen the compliance suite. I focused on specifics from the teleconference that others ignored. As the transcript indicates, Carla Schroer mentions the packages that failed compliance, while Alan Baratz discusses Microsoft specifically failing the signature test part of the compliance tests. While I have seen mention of the specific packages that failed in some other articles, I don’t recall seeing any mention of the signature test failure. I thought the readers of JavaWorld would be interested and understand this. Other people who covered the news might have thought differently of their readers. If you just want one article that is critical of Sun, the obvious candidate is Daniel Steinberg’s “Java development on Macintosh — is it viable or not?” in the August issue. Using the topical index at http://www.javaworld.com/common/jw-topicalindex.html, I was able to locate http://www.javaworld.com/jw-07-1997/jw-07-javamac.html fairly quickly. I’m sure there are more. John

John,

I really enjoyed your article. I have a question: Do you know where one can find a list of the classes/methods from the Core API that Microsoft has modified? It would be a service to your readers to let us know precisely what methods to avoid.

Much thanks,

Brian Bartell

Brian, I haven’t seen a list posted publicly yet. However, to give you an idea of one of the changes, if you look at the java.awt.Font class, Microsoft’s Font class adds a public method called getNativeData(). Microsoft also made an instance variable public that is private in Sun’s implementation. John

John,

Is there a list of the methods and fields Microsoft added to its java libraries?

Adam

John,

Great piece! I posted the URL to the mailing list for the Java Lobby, but you’d probably get a bunch of interest if you posted there too. See https://www.javalobby.com.

I’d like to see you put up a “FAQ” on this subject with headings like “Building 100% Pure Apps is MS JSDK” and “Building “100% Pure Apps that run under IE 4.0.”

Michael Sick

John,

I read your article on the differences between Microsoft’s SDK and Sun’s JDK. This is something that really interests me at the moment, and I have a question about your research. You said:

“There is an exception to this com.ms avoidance rule though: Microsoft’s Application Foundation Classes (AFC) in com.ms.ui (see Resources) are written in Java. So you can use them. However, if your users are not using IE 4.0, you will need to provide them separately.”

This leads me to think that AFC is 100% pure Java. I was wondering if you have verified that AFC is pure Java by trying to run AFC apps on a non-Microsoft platform? Thanks for your time.

Jeff Sider, Java Consultant

SIDC Software Development Inc.

John,

Great article on MS Java pitfalls. Can’t get much timelier than that. However, I wanted to point out that https://www.stinky.com/java/msdiff.txt lists a number of differences that are not listed in your (very good) article. The URL above claims that there are also extra methods in

java.lang.reflect.Method,
                                       java.lang.VerifyError,
                                       java.util.Locale,
                                       java.awt.Label, 
                                       java.util.ResourceBundle,
                                       java.awt.ScrollPane, 
                                       java.awt.Frame, and
                                       java.awt.Window.
                                      

You may want to check into this and update your article as appropriate.

Charles Kerr

Charles, Thanks for the pointer on the diff file. Looking in the file, I don’t see any mention of the problems in java.awt.Label/ScrollPane/Frame/Window. Let us know what your source was for these. John

John,

Is it possible to replace the Microsoft VM with the JRE from Sun? If so, how? Can it be done without a client install?

Steve Potell

John,

For fun, I suggest you have Zukowski do same analysis on Netscape’s JDK 1.1 beta…

Charles Fitzgerald

Microsoft Java Team

http://www.microsoft.com/java

John,

Great article on the SDK differences. This was a real service to the community.

Thanks and keep up the good work,

Mike Daconta

John,

Just a short note on one part of your article. Maybe it’s useful information that can be incorporated into the article. You write:

Another difference is that the Dialog class will accept a null parent Frame parameter for Microsoft, while the Sun JDK throws an IllegalArgumentException.

This throwing of an IllegalArgumentException has been driving me crazy for quite some time, because in Patrick Chan’s and Rosanna Lee’s The Java Class Libraries — An Annotated Reference (which seems to be quite official as it is part of “The Java Series … from the source”) it says:

: public Dialog(Frame parent, boolean modal) : […] : parent The parent of the dialog. Can be null.

And you write,

Hopefully, any improvements made by Microsoft will make their way back into the JDK and vice versa.

Yep, 100% pure truth. 😉

Thomas Pluempe

P.S. Thanks for the article, I asked Sun to provide that information, but they have not yet answered.

Thomas, With regards to the problem you are having, this is listed as an incompatible change in the AWT 1.1 API. See https://java.sun.com/products/jdk/1.1/docs/guide/awt/IncompatibleChanges.html for a complete list. The Chan/Lee book you have is based on Java 1.0, so it still lists the old way. John

John,

The package name of “com.ms.xxxx” doesn’t even follow the de facto standard of inverting one’s domain name. A naive user might contact Morgan Stanley Dean Witter if they found problems with the Microsoft code, since Morgan Stanley is the apparent owner of the “ms.com” domain.

Mark Smith

John,

Cool article.

There are a few points I’d like to make. (I’ve done my own very quick comparison between SDK and JDK1.1.4, and came up with the same conclusions as you.)

You wrote:

There is an exception to this com.ms avoidance rule though: Microsoft’s Application Foundation Classes (AFC) in com.ms.ui (see Resources) are written in Java. So you can use them. However, if your users are not using IE 4.0, you will need to provide them separately.

While trying to run one of the AFC demos, I discovered that AFC uses the SystemColor.appWorkspace field! So, AFC is not exactly portable, you have to be using the Microsoft JVM.

🙂

Matt Quail

John,

Excellent article, John.

I want to point one thing out though. AFC is dependent on some of the enhancements that Microsoft added to the java.* packages. I know this because I tried to extract the AFC packages and move them to another platform. It complained about not finding some of the methods missing in the toolkit package. Microsoft plans to rectify this with the cross-platform version of the AFC package, but this will be a separate version of AFC. It seems to me that this actually makes code maintenance more difficult for them.

If Microsoft would simply eliminate the new classes and methods from the java.* packages, I would be very satisfied with its 1.1 Java implementation. I know I don’t speak with the majority of Java developers though. I personally don’t feel that RMI is that important. I’d prefer a CORBA add-on. Besides, I can still perform the same types of remote interfaces with CORBA. I also don’t think the JNI/RNI issue is relevant. Anyone trying to write “pure Java” is probably not interested in writing native code.

Thanks again.

Bill Hyman

John,

Have you had any success extracting the classes.zip file from IE 4.0 or SDK 2.0? Microsoft seems to put the classes in a .lib file which is a total pain!

All I really want are the classes proper.

Thanks.

Madhu Siddalingaiah

Madhu, If you install either, the classes.zip file is located (on my NT4 box) in winntjavaclasses.zip. If you prefer not to install, you can get the CAB Development Kit from Microsoft and use their CAB file extractor tool (whose name I don’t recall — although this is supposed to be included with Win 95 systems). This will allow you to extract the classes.zip file from the .CAB files that you d/l from Microsoft for the software. Its actually inside a cab file inside a cab file, vs. just one level deep. Good luck,

John

John,

I just read your article at http://www.javaworld.com/jw-10-1997/jw-10-sdk.html, and I am curious about the applet on URL https://www.javasoft.com/docs/books/tutorial/intl/datamgmt/index.html

I’m running IE 4.0, and the applet says “Your browser can’t run 1.1 applets.” Did you check the java.text classes, and in particular the Format and all related classes? I didn’t find a reference to it in your article.

Regards,

Filip Van Laenen

John,

Saw your article about compatibility problems in the JVM that ships with IE 4. I understand that the JVM that ships with Communicator 4 has similar problems of modified java.* class libraries. Do you have any plans to do an article on the Communicator compatibility issues?

Also, I just picked up a copy of Symantec Cafe 2.0. The release notes seem to indicate that there are still some pretty serious bugs in the Sun awt.* 1.1 class libraries. For example, mousedown events are lost. What’s a Java developer to do?

Richard M. Smith

Richard, Thanks for the comments. If you look at the very bottom of the article, there is a sidebar mentioning the Java 1.1 patch for Communicator 4.0 differences. Regarding Cafe, I just got the 2.0 release yesterday. Where do they mention this? You might consider taking a look at Sun’s Bug Parade (http://developer.javasoft.com/developer/bugParade/) and vote on the ones most important to you. John

John,

You might consider an article on the techniques of writing code that is tolerant of platform differences.

Let me give you an extreme example. This was Smalltalk, but the ideas are the same. At Polymorphic Software Inc. we had a transparent persistence system called Tensegrity and a direct manipulation graphic framework called GF/ST.

The company was bought by ParcPlace and the products have essentially disappeared, but that’s another story.

GF/ST lives on in the form of the jKitGO from ObjectShare.

Both of these products were written with a common code base in the Envy repository and had versions for VisualWorks, VisualSmalltalk and IBM Smalltalk. About 15 percent of each were adapters to each of the platforms. But 85 percent was common.

Both of these products were in pretty difficult programming areas. And these three Smalltalks were vastly more different than the relatively small differences that are happening in Java.

The solution is based on good object design and on the power of the Envy code manager.

There are other Smalltalk third party companies that got pretty good at doing the same stuff.

All of us came to the same conclusion — designs for portability are good designs. If it is done well, then the result is very strong stable code.

Ed Shirk

Ed, Thanks for the note. Sun actually includes lots of the necessary techniques in the 100% Pure Java cookbook (like not using “/” or “” in a filename, but file.separator instead). The techniques do go beyond that and I’ll think about it for a future article. John

John,

Companies have been extending languages as a way to corner users into their implementation for a long time. This practice hardly begins with Microsoft. You failed to explain why, in this case, it is wrong for Microsoft to repeat this practice.

You made a case for the “write once, run anywhere” argument, but that was never a Microsoft argument. Why, beyond the purity of a competitor’s vision, should Microsoft refrain from extending the core .java classes? If Sun is truly committed to the concept, why shouldn’t Sun modify their class libraries to match?

As an alternative: Why shouldn’t Unix developers simply develop on a Unix machine and port to NT, thereby insuring that their code is “pure java” if that is their intent?

The Microsoft product is called J++. The obvious message is “this is more than just Java.”

What advantage is there to having only one company be the sole source of improvements in a programming environment? Are you advocating a command-and-control model for an Internet technology? Think before you answer that question.

By the way, just as DCOM is not supported on Unix, CORBA is not a viable option on NT. You can blame anyone you want, but don’t deceive yourself. Without Microsoft’s support, CORBA on the NT platform is dead-on-arrival. Since CORBA is useless for NT development, I use DCOM, which is fast and efficient.

The Java-to-Java mechanism you described is clearly a competitor to both CORBA and DCOM, and is therefore a duplication of function. Are you saying that CORBA is not sufficient to serve the purpose? Why should a programmer care if the other side of the RPC call is Java? Why should we have to learn two RPC mechanisms (one for Java, and another for non-Java remote objects)? Give me one mechanism for all remote objects.

If I use the Java-to-Java mechanism, I force myself to write the other component in Java, which prevents me from using a fast language, like C++, or a less expensive language to maintain, like VB. (speed tests published in the VB Programmers Journal show Java objects on the NT platform to run considerably slower than both VB and C++).

Reality check: Microsoft cannot support CORBA to the detriment of DCOM. Sun is simply being partisan when they insist. Their efforts are as transparent as those of any politician in Washington these days. With so small of a desktop installed base, CORBA cannot win without Microsoft. As it currently stands, CORBA is no more of a complete solution than DCOM is.

Obviously, a middle ground must be found to support both CORBA and DCOM. Perhaps a future RPC standard that can communicate with both. Regardless, the “bastard child” Java-to-java mechanism should be allowed to die a natural death. (Unless CORBA is so slow that an additional mechanism is necessary, which would be a flaw in CORBA, and not by itself a reason to use the Java mechanism).

In all, your article failed to address any of the real reasons why this war is going on, and is therefore, simple FUD. You raise an alarm without justifying the call. You call developers to defend what you do not defend yourself. By using implied reasoning, your article can only be taken on faith, and I do not share your faith. You are preaching to the choir.

Respectfully,

Nick Malik

(Standard disclaimer: The opinions I have expressed are my own, and are not necessarily shared by my employer, coworkers, or their domestic pets.)

Nick, Thanks for the note and expressing your differing opinions. We’ll just let the courts decide what Microsoft can and can’t do with regard to Java. Regarding the J++ name on MS’s Java product, in order for MS to use the Java name, they needed Sun’s okay. As the VM that comes with J++ is not Sun’s, I suspect that is why the name is different. Now that the contract is out in the open, one can read the legalese and try to figure out what can and can’t be done. While some things seem to be gray areas, it does seem Microsoft needs to pass the compatibility tests, which they didn’t. If you care to create Java programs that are MS Windows specific, go ahead. In creating the article, I tried to point out the areas that developers need to be careful with when trying to create cross-platform Java solutions. Regarding RMI, CORBA, and DCOM, RMI provides a lightweight solution where you don’t have to go through the overhead of creating a cross platform/language level. If that is the most appropriate solution for a problem, then use it. If not, then you need to move on to something heavier, like CORBA or DCOM. I am not asking for MS to support CORBA, only RMI. As the RMI classes are now available on Microsoft’s Web site, that doesn’t appear to be a problem any more. Again, thanks for the note. John

John,

An issue to highlight would be the effect of Microsoft’s Studio product using java.* extensions automagically. That would mean silent lock in…

Neil Corlett

Neil, Thanks for the note. I’m not a Microsoft Studio user/owner. If you happen to have it and can test out your theory, I’d love to hear the results though. John

John,

Great article on IE 4.0 compatibility issues. I’m sure you are aware the article did not address all the issues. Here is one that I did not find mentioned in the article.

Run the applet at https://www.sc-systems.com/public/misc/IE4MenuBug and note that when run on IE 4.0 the menus do not display on the applet frame. When run on any other Java enabled browser the menus display properly. This is a simple 1.0.2 applet.

David Boydston

David, Thanks for the note. I appreciate you pointing out yet another behavioral difference between IE and everything else. I keep hearing about more of them. I didn’t try to list all of these types of differences but did try to point out some. Thanks for bringing this one to my attention. Its amazing all the problems encountered so far looking beyond just the API. John

John,

Nice article. I did a quick analysis myself and I think Microsoft also made Win32Process public. If I’m correct, that class should also be avoided.

Cheers,

Pat Chan

John,

One thing I found from the java.util.Locale javadoc on Microsoft’s Web site was a new Locale constructor that took 2 additional parameters for Win32 locale ID’s — while I would obviously avoid such a constructor to write portable code … it is another indicator that shows that MS has added code to the core classes that are clearly not portable! Bill Siggelkow

John,

You missed one giant anomaly in the article: When producing a frame from a Java applet in IE 4.0, all graphics drawn directly to the getGraphics() context are shifted up by approximately 12 pixels. (The size of the frames title bar). This doesn’t apply to GUI elements.

That is to say, the coordinates for graphics drawn directly in a frame start at 0,0 _in the title bar_!

I’m facing a dilemma: I have a program that opens a frame and mixes graphics with GUI elements. My customer wants a program that looks good in IE 4.0, but this would mean shifting the graphics in every other browser.

This is certainly a bug, but whether it is intentional is another question.

Jesper Juul

John,

Thank you for your helpful article regarding Microsoft’s changes regarding what appears now to be two separate JDK’s.

The article was very informative and I’m sure I’ll reference it in the future.

I have a quick question for you. I’ve been using Visual Cafe for Java development, but have been eyeing J++ (because it’s part of Microsoft’s “Visual Studio” integrated Internet application development) and was wondering how each compares, particularly in the area of the AWT GUI development. I really like Symantec’s “drag and drop” simplicity for making great looking interfaces and was wondering if J++’s environment compares. Any information would be appreciated.

Alan Snyder

Alan, Thanks for the note. The Visual Cafe 2.0 environment is a Java 1.1 environment. As such, it uses the JavaBeans model for AWT/GUI development. J++ from Microsoft is still not a Java 1.1 environment. There is another article in the November issue that compares four of the Java 1.1 environments, JBuilder, VisualAge for Java, Java Workshop, and Cafe. If J++ was a Java 1.1 environment, it would have been included in the review. Borland has an interesting comparison of J++ and JBuilder at their Web site too… Good luck with Cafe. John

John,

Isn’t this kind of a reach?

Unlike Microsoft, Netscape does not offer an environment for Java development. (Visual JavaScript uses JavaScript to connect JavaBeans, not Java.) To use these methods, developers have to go out of their way to access them in source (and know that they are there).

Are you going to go back and look at Nav3? It is a lot more work, but I predict the results will be worth it journalistically.

Charles Fitzgerald

Microsoft Java Team

http://www.microsoft.com/java

Editor’s Note

The revised version of Zukowski’s article posted 10/15/97 includes a sidbar analyzing the Netscape beta.

John,

Here’s an interesting item I found on Usenet that dovetails nicely with your “Microsoft Java Pitfalls” article. Rob McDermid from Hummingbird Corp (the X server people!) reports:

Ok, I just got bit by Microsoft. It seems Sun’s allegations about Microsoft modifying core java files are true, and I can now see why they are upset about it.

Yesterday, I discovered that the java.awt.SystemColor class that Microsoft supplies contains an extra field, appWorkSpace. Now, at first, this doesn’t seem like a big deal – as long as you don’t use it, your code is still 100% pure. Problem is, it’s pretty easy to forget not to use it, and it looks like the people that wrote AFC did. The class awtUIApplet references this field. This means that any program that uses awtUIApplet cannot run on anything exceptIE 4.0. In fact, even IE 3.0 cannot run it. I suspect this was not deliberate on the part of the AFC writers, since they claim that they are going to support Netscape, but it goes to show how easy it is to slip up when your core classes have been modified.

Has anyone else run across this? As far as I can tell (I’m just learning AFC) you _have_ to use awtUIApplet to write any applet. The code I am using is the AFCSkeleton program that Microsoft provides. Is it true that you have to use awtUIApplet, or can this be avoided?

Thought you’d be interested.

Charles Kerr

John,

Thank you for a most welcome article!

You write:

Missing ByteArrayOutputStream[…] Yes, developers can work around the missing method easily[…] however, this could force endless wasted technical support hours[…]

There are two things I particularly have a problem with:

• Microsoft, and some others, don’t care how much time is unnecessarily spent on technical support.
• Most developers don’t give a damn about how much they waste peoples’ hard disks.

Instead of being investigated over anti-competitive practices, Microsoft should get sued over the low quality (unreliability and inconsistency) of their operating systems and applications.

Lately there has been some discussion about how much it costs to have a PC around. I think much of that cost comes from incoherent applications with plain sloppy help systems. Think of the cumulative effect on GDP of all unnecessary head scratching and real work time wasted.

Hard disk space seems to be an unlimited resource, at least for developers. I find application data files full of empty holes (e.g. 2k of NULL characters every few k), and the size of my text saved with successive versions of Microsoft Word keeps growing exponentially.

Not that Microsoft is the only one to blame. Even compiler vendors should look at themselves. Try compiling Hello, World with Borland’s latest C++ compiler.

Back when I started in this business we had a high-end office computer with a large hard disk, and it could run all the office applications of the day with no problems. The hard disk was 10M and CPU memory was 64k.

Today I’m running a desktop a thousand times faster, with 10G and 64M, and I’m struggling.

Georg Wrede, Analyst

Swedish School of Economics and Business Administration

Helsinki, Finland

John,

Thanks for your article at JavaWorld. I’m hoping you might be able to clear up a question that I’ve been trying to answer for a long time. Can you use the MemoryImageSource class to create an image from an array of bytes that hold the contents of a compressed JPEG image file? I have seen examples of this posted around the net but not one of them actually seems to work. Most of the examples actually use an uncompressed array of pixel bytes or ints.

Any clarification would be greatly appreciated.

Thanks,

Pete Prokopowicz

Pete, The Toolkit.createImage() method allows you to create an image from a byte array, where the image data in the array is encoded in GIF/JPEG format. The method is only available in Java 1.1 environments. John