This month we'll start off with some discussion about what is happening to the Java support for the platforms that are not one of Sun's big three (i.e., Solaris, Win95/NT, and MacOS) platform priorities. Then we'll move on to cool topics.
In the beginning there was Oak. It was totally proprietary and hidden from normal view. Oak blossomed into Java and addicted vast legions of people because it was basically free. The fact that anyone could get the Java source code and port it to new platforms and release his binaries to the public was a clear statement that Sun was serious about making Java an open platform.
I am often asked whether and when there will be support for other platforms. Sun officially only supports its own Solaris 2.x for SPARC and x86, Microsoft's Windows 95 & NT, and Apple's MacOS.
Sun has commercially licensed Java to the likes of Borland, HP, IBM, Microsoft, Oracle, Silicon Graphics, and Symantec (check out Sun's Java licensees for a more complete list). A good portion of the licensees are porting Java to a number of additional platforms. Unfortunately, many platforms (such as FreeBSD, GEOS, Linux, and even Sun's own SunOS) are not targeted for a Java port by any commercial licensee. To fill the gap, a number of individuals have taken the task upon themselves to produce ports to some of those commercially unsupported platforms.
Randy Chapman took on the porting task for the Linux Java community. The success of this and other non-commercial porting projects helped to solidify the notion that Java was truly going to be an open, cross-platform solution. Sure, the commercial licensees like SGI, Symantec, Microsoft, and Borland have helped to legitimize and strengthen the Java movement, but a good chunk of the huge Java groundswell has been from folks using the "fringe" systems like Linux.
The porting problem has been creeping up on everyone since the v1.0 beta releases. The license agreements in the earlier releases sounded quite clear on the issues of distributing ported Sun Java tools in binary format (note that source code redistribution has never been allowed). The licensing agreements in the more recent releases, however, have seemingly become increasingly strict for the non-commercial licensees. The original Oak/Java team may have threatened to leave en masse if the pre-alpha version was not made "freely available," but since that time many of them have left Sun/JavaSoft anyway, so some folks fear that the lawyers have taken firm control of Java at this point and that the licensing terms will only get tighter.
As of this writing, there are no plans for a Linux port of the Java Developer's Kit (JDK) 1.0.2 or any subsequent version. Given that the Linux port has been a sort of flagship for other free porting groups, it is likely that the other groups will follow the Linux port's lead. The JDK 1.0.2 license is, according to the non-commercial porting folks, too ambiguous for them to continue. It seems to imply that by releasing the binaries they have created by porting the Sun Java source code, these groups are opening themselves to some potentially severe legal action from Sun. The porters do not feel it is worth the risk of Sun suing them into the oblivion (er, um, for "damages") when they have done all of this work for the benefit of the Java community (and hence, for Sun). I have not been privy to any of the private communication between the porting folks and Sun, but it has been pretty clear in the reports to the Linux Java community that until yesterday Sun has basically ignored all efforts to clarify and try to rectify the situation.
So, some have asked, what is the big deal? Sun makes sure Java works on Solaris, Win95/NT, and MacOS and that covers that vast majority of the general-purpose computing machines on the planet, right? Well, by that logic, just supporting Win95 covers the majority of machines on the planet (certainly to a first-order approximation), so why support any platform besides Win95?
Some free-software folks are quick to say there has been work on "free" clones of the various Java components for a while. Check out the Java Open Language Toolkit (JOLT) Project. There you will find a free source-to-bytecode compiler called guavac and a free Java bytecode interpreter known as kaffe, and there is even work happening on a free JIT compiler. Unfortunately, with the Java landscape changing so rapidly, these free tools will likely always be playing catch-up, and so true interoperability may be a problem.
The fundamental question is whether or not Java is truly going to be an open, cross-platform technology. Randy Chapman and others have done a wonderful job finding and fixing numerous bugs in the Java implementation and turning them over to Sun for inclusion into the baseline code, and all the while have helped the proliferation of Java. Perhaps Sun sees these pesky free operating systems as eroding its "real" business of selling hardware. Maybe Sun has just been too darn busy with other, higher-priority issues (like getting the AWT code to work nicely under Win95). Or perhaps this licensing issue has just fallen through the cracks. Regardless, this licensing confusion must be resolved.
Well, as of yesterday, August 13th, a JavaSoft spokesperson has taken up the task of getting the proper folks on both sides of the issue to communicate so that the concerns of the porting people can be voiced directly to the people at Sun who can address the issues directly. I talked with the JavaSoft spokesperson today, and while she obviously could not comment on the outcome of the discussions, she did say that Sun's original intentions for Java have not changed and that hopefully this has all just been a result of poor communication.
Well, no one can say when this will be resolved, but I will definitely keep you posted.
A lot of people are still asking for Java support for SunOS. Sun seems to have completely written off Java support for its own SunOS platforms. An unofficial hack was attempted by some group inside of Sun for internal use, but it seems to have died. Some speculate that Sun sees the lack of Java for SunOS as yet another prod to get all you SunOS holdouts to finally upgrade to Solaris 2.x.
Reader Mark O'Driscoll writes that he successfully employed the trick of using Netscape's Navigator to compile Java source on SunOS (check out JavaWorld's Java Tips section for more details) but, alas, he could not run the code.
If you can afford it, you might want to check out Visix's Eleven. It is based on the company's Galaxy cross-platform technology, which does run on SunOS, so Eleven may support it.
Also check out the free Java clones from the JOLT project (mentioned above). JOLT's initial target is Linux, but the project aims to support as many platforms as it can.
Loading HTML into frames
Pac-Man from France asks: How do I load an HTML file into my applet? Also, how do I load the HTML file into a different frame?
Well, I am going to assume that by loading an HTML file "into" your applet you mean load the specified HTML over the current page. The single-argument version of an AppletContext's showDocument() method will replace the current page with the page from the specified URL.
Loading an HTML page (as given by a URL) into a frame is accomplished by using the two-argument version of an AppletContext's showDocument() method. The first argument is the URL to load while the second is a string that specifies where to display the page. According to The Java Application Programming Interface, Volume 2, the possible values for the target display are: "_self" to use the current frame, "_parent" to use the parent frame, "_top" to use the topmost frame, "_blank" to use a new, unnamed frame; otherwise the string is taken to be the name of the frame in which you wish to display the page.
Loading pages from Oracle
Ravi Kale says: I want to read an HTML page/file generated by the Oracle Web Server on the fly.
Hmm... I do not have any experience with the Oracle Web Server. You might want to check out the article by Jack Haverty in the Editorial Pulse section of Oracle's Developer Programme. Note though that I would not know what it says since Oracle requires one to be a registered member of their program to get it.
You can use the showDocument() methods discussed above once you determine the URL of the generated page (which, I presume, is discussed by the Oracle Web Server documentation).
Question: Will Java replace Perl as the server-side/cgi-bin coding solution?
Who knows? Perl has been around since the beginning of the webolution (Web revolution), so it is fairly mature. The Perl modules for dealing with HTML, CGI, etc. are pretty nice and relatively easy to use.
Java on the server side of the fence is fairly immature. There are, however, a number of HTTP servers already written in Java, including Sun's Jeeves Internet Server and the WWW Consortium's Jigsaw HTTP Server. Both support the idea of servlets -- that is, the use of Java code running on the server to do work. I also expect someone to add a Java servlet module to the popular Apache server real soon now; somebody please tell me if I missed the announcement! :-).
Being able to code in Java for both the client and server sides has been possible since Java was created. Unfortunately, the server-side Java was a separate, standalone Java application that had to do pretty much everything itself. The servlet capability puts server-side Java code within a nice framework akin to applets inside browsers.
Inter-applet communication update
A quick update on the inter-applet communication solution mentioned last time: The static data member "trick" that was used to communicate between applets is no longer valid. The powers that be decided it is a Bad Thing(tm) for various reasons. This affects the newer versions of the Sun JDK and anything based on it (such as Netscape Navigator 3.0 betas).
Mike Pagano asks: Does Mountain Dew aid in Java programming?
Well, I do not drink Mountain Dew at all and just imagining mixing it with some hot Java sounds nauseating. It does have the most caffeine in any "normal" soft drink. However, it does not measure up to Jolt Cola or any of the other new caffeine and sugar overkill drinks. Personally, I am quite partial to Henry Weinhart's Draught Style Head, Premium Root Beer.
Philosophically, I would suggest keeping a variety of drinks on hand for those late-night Java programming sessions. The variety of sensory stimulation can help jar your subconscious into revealing to you the silly error you made that you have been futilely bug-hunting for the last hour or three. Altering your choice of background (or foreground) music while programming can help/hinder your thinking as well.
Enough ranting and raving for this month. Go wild!
Learn more about this topic
- Sun Java Source Release
- Java Licensees
- Linux Java
- JOLT Project
- Oracle Developer Programme
- Sun's Jeeves Internet Server
- WWW Consortium's Jigsaw HTTP Server
- July JavaWorld Q & A