Letters to the Editor

James Gosling makes a cameo appearance to set the record straight (as only he can) on an increasingly relevant question: Why were enumerated types left out of the Java spec, anyway? Plus: Reader praise (and plenty of technical Q&A) for Jon Steelman, Bill Venners, and John D. Mitchell; and, for the second month running, JavaWorld's publisher takes heat for our excitable ads

1 2 Page 2
Page 2 of 2

How can I get an applet to write/read to/from the disk where it is running?

Armin Guenther

Armin, A standard applet cannot do that. Signed applets can potentially do that, but the state of signed applet support in the various browsers is questionable. You can learn more about applet signing by reading the Applet Signing FAQ, which is floating around in the comp.lang.java.programmer newsgroup. You can also read the various security and signing documentation that is available on Sun's Java Web site. Netscape has it's own "Capability" API for allowing applets to do various levels of things on a local machine. Check out the documentation on Netscape's Developer Web site. John D Mitchell

Java optimization resources

John,

Thanks for compiling the very useful Java Tips in JavaWorld magazine. I especially found Java Tip 26 quite useful. I'm looking for general guidelines on performance tuning/optimization of Java code. Could you please let me know of any resources (or books) where I can find this kind of information?

Nagendra G. Nirnakar

Nagendra, I'm a firm adherent to the notion that premature optimization is the root of all evil. The first (and best) step to make with respect to performance is to learn/find good algorithms and designs for whatever problems you're solving. After that, take the time to learn the way things are done in the language/system that you're using -- in the case of Java, a myriad of books, magazines (like JavaWorld), references, and the like are readily available. Additionally, writing the code for correctness and then profiling your code will help you to see what areas are worth improving. For a more bottom-up point of view, learn about the design and implementation of the Java virtual machine and the bytecode language for it. Dump your class files out and look at the generated bytecode. For something in between the two extremes, check out the various FAQs, and use the search engines on the Net and on the various specific Web sites (like the JavaWorld search engine). There's a fair bit of stuff floating around out there. John D. Mitchell

Passing parameters between applets

John,

We are trying to pass parameters from one applet to an applet located on different Web page (not within different frames, they are totally different Web pages). How can we do this?

K.C. Liu

K.C., Check out Java Tip 3 for information on how two applets on different Web pages communicate. Unfortunately, there is no portable way to pass parameters directly from applet to applet when there is no direct connection between them mostly due to security concerns. There are various tricks you can do with JavaScript but that's outside the scope of pure Java solutions and JavaScript solutions certainly aren't portable. Truly, the most reliable, portable solution is to use a common server that each applet can talk to. The server can then mediate the applets' discussions. John D. Mitchell

Letters to the editor

Java believer says it's time to bury the hatchet with MS

To the editor:

I've been a Microsoft basher for many years -- long before Java arrived on the scene. In the mid '80s I lamented over the OS wars and now I lament over the browser wars.

But recently I find myself burying the hatchet. Why? Certainly not because Microsoft has changed its unethical ways but because for the first time it's about to help advance the state of the art rather than hinder it. I'm talking about Windows 98, DOM, XML, scriptlets, and active desktop. At long last we'll be able to advance GUIs to the next step of true programmability. This is an area that has not seen true innovation since the early '80s.

Our culture is about to embark on the extranet and virtual corporate adventure. The fastest way to make that happen is XML and scripting. Scriptlets (with COM under the covers) does away with the need for CORBA or Java in such applications.

I bet the farm on Java a year and a half ago. I quit my job and became a contributing author to two titles for Java. I've written much freeware for Java including a generic server toolkit including a proxy and Web server. I've worked several contracts with Java and turned off many an IT manager with my zealous advocation of Java.

All I have to say to my fellow Java believers is to conduct this simple exercise: Build an extranet application with strictly Java. Then try it with XML or MS DHTML with data binding. Which is easiest, fastest, cheapest? By the end of this year the power of XML and MS DHTML with scriptlets will be apparent.

The Java community fell in love with Java because it's truly a wonderful, easy, and fun language. The cross-platform dream simply made it all the more wonderful. But consider the fact that Internet Explorer is rapidly becoming the cross-platform browser. Also consider the greater ease of building content-intensive apps with a content language like XML, versus a computative-intensive language like Java, and you may well find yourself falling in love all over again.

Java is here to stay, in embedded systems and dedicated distributed apps, middleware, etc. But Microsoft's vision of Java as a component building language is correct. VJ++ is an attempt to optimize Java for that role, and by so doing Microsoft is taking Java where JavaSoft will never take it -- to the extranet content delivery world. Seen in that light, the 100% Pure Java initiative while being cross-platform-computing inclined misses the most vital concepts of our era: connectedness and the flow of content.

Microsoft can afford to lose the Java zealots because by next year XML's power in the extranet will be starting to be felt in a very strong way. At that point you'll see XML and remote-scriptlet envy.

The world is changing constantly. For once Microsoft is advancing the cause of computer science rather than exploiting the inventions of others. I think it's ironic that the DOJ may negatively affect this advancement, instead of stopping Microsoft years ago when it was destroying Dr. DOS, WordPerfect, Lattice C, Paradox, Lotus, etc.

John Small

Riled up over JavaWorld ads and parameters

To the editor:

Two things:

First, is it really necessary to apply a parameter like ?051198txt to all of your URLs? This is really bad, because many proxy caches do not cache URLs, which include parameters, and I don't like to add the rule/burden of parsing such URLs.

It always takes a long time to download these articles. From my point of view there isn't any need to apply parameters to such URLs, as each article is pretty static. Of course, maybe your intention is to track the access to these articles, but you should take into account that there are other ways to get around this problem.

Second, I don't like all these ads on your pages. It wouldn't be a problem if the ad servers were fast and the download of these images didn't take so long, but they are often very slow. As a result, our university has redirected all ad image downloads to a transparent GIF, located at our site, which speeds up the presentation of your pages.

My suggestion is to organize your Web service to be more cache friendly and remove the ads or put them on your server with a static URL (that is, no parameters).

Jens Elkner

Jens, First, I assume you are referring to the trackable links in our e-mail alerts. I'm not certain about caching problems they create, but I'm guessing your concern is that they don't match up with the pages you've cached in advance (having stripped out our ads). When you strip out the ads for your readers, you are ensuring that our revenues are dampened, which makes it harder for us to prosper. JavaWorld is supported almost exclusively through advertising; this is our livelihood. In other words, no ads, no magazine. Second, caching everything means we can't track pages, which means we don't know what's going on, which means we are running blind. Not the best way to understand how our readers are responding to our efforts. Third, caching ads means we can't report on ad traffic, which means we don't get paid, which means we go out of business -- not our preferred outcome. Ideally, we'd be able to serve ads and pages without disturbing caching, which would be best for everyone -- we'd be able to track things, readers would get pages served faster. It's a less than ideal world, however. We are switching to a new ad serving service in the summer; they claim they are able to track ads served without clearing cache. If it works in practice, it will be a big help to all concerned. In the end, Jens, I can only work with what I've got; this business is in a technically early and primitive stage. Michael McCarthy

Web Publishing Inc.

mac@wpi.com

Related:
1 2 Page 2
Page 2 of 2