The answer to the question "Will Java remain `open'?"

Sun sheds some light on the Java licensing situation

We begin with an update of the Java licensing situation brought up last month. Then we'll dive into reader questions.

Java licensing update

The Java licensing hullabaloo that we discussed

last month

drags on, but the major question of Sun's intentions about Java's openness has now been answered.

Here's a quick recap of the situation: Due to mounting concerns over Sun's licensing terms, the folks doing the non-commercial ports of Java "fringe" platforms like Linux pulled the plug on the port of the Sun JDK v. 1.0.2.

Since last month, the Sun folks have described this occurrence as a case of confusion between the non-commercial and commercial licenses. The Sun folks then explained their position, saying:

"...the bottom line is that JavaSoft welcomes and encourages the distribution of non-commercial ports, and we are sorry that any confusion existed on this issue. It seems our fault existed in not responding quickly enough to your diligent inquiries for further information."

The above statement does not put the matter to rest entirely; the porters are waiting for Sun's response on a few issues. As of this writing, Sun still has not given explanations. Because it appears that these relatively minor issues will be resolved reasonably, work on the port itself has been resumed. The port will not be released until the issues are finally resolved.

The bottom line is that it looks like Sun is relatively serious about seeing that the "openness" of Java is preserved. Yea!!!

List broken?

Question: The following code works under the Appletviewer but draws nothing under Netscape. What's up?

import java.applet.Applet;
import java.awt.List;
public class simple extends Applet
{
    public void init()
    {
    List foo = new List (4,true);
    this.add(foo);
    }
}

Well, I would say that it is a question of interpretation of what the abstract windowing toolkit (AWT) is supposed to do in this situation (where the created list is empty).

The applet is there and is running. Under Netscape 3.0, if the list does not have any entries then it will not build-out/draw the list.

One trick could have been to put something like " " as the only item in the list and then delete it after the list has been built. Unfortunately, in this case and any of the simple variations thereof, it will only build out a list that has one visible element.

Also note that it only builds out MIN(visible list elements value [e.g., 4], the number of actually added items) so in this case you will have to do foo.addItem (" ") four times! But note that the list will not have a scrollbar; if you want to have it build out with a scrollbar initially, you should use n+1 (e.g., 5) instead.

At this point, if you really want to have an empty list, you will have to do something more complex.

Serial port access

Jim Field asks: How do you get a Java application to send data out the serial port (COM1 or 2) of the PC?

Since this sort of low-level system access is not portable, there is no portable Java way to do it. You will need to resort to writing Java native methods -- that is, C code which does the actual work. You write Java "wrappers" for the C code to make it available to your Java code.

A tutorial on writing native methods is available from the online version of Sun's The Java Tutorial by Mary Campione and Kathy Walrath.

Page-hit counters

Mark Roth asks: I've been hunting high and low for a Java script or Java page-based hit counter. My system administrator doesn't want anything of this in his cgi-bin directory.

I guess I'm confused by the situation that you are in. If your system administrator will not allow you to run programs on the server side, then how would you run a Java application to update the hit-counter file?

A Java applet would have to connect to some running program on the server that would do the actual page-hit counter update and reporting. You can find some examples of this via the Gamelan Java Directory under the Networks resources in the Networks and Communications section.

Page-hit counters and file locking

Jeffery Anderson asks: How would you implement file locking in Java? For instance, I want to create an access counter for my Web site using Java, and I want to lock the file containing the number of hits to prevent it from being over-written.

Well, I can think of at least three methods. If you want to work just at the Java level then you could create a regular file using java.io.File.File() as a file system-level semaphore that your hit-counter file is in use. That is, if your hit-counter file is "hits.txt" then before opening it see if the lockfile (say, "hits.lck") exists using java.io.File.exists(). If the lockfile exists then one of your other threads is currently accessing it. If it does not exist then the hit-counter is available; you then create the lockfile and open the hit-counter file itself. When you're done updating the hit-counter file, close it and then delete the lockfile. While this is relatively simple to implement, you have to worry about things like race conditions, and you may not have any control over other programs that will access the hit-counter file. Basically, this would be a reasonable solution if your application is the only thing that touches the file, and only one copy of it is running at a time.

The other two options use the same underlying method to lock the file. The idea here is to write C code as either a stand-alone program or as a Java native method, which does the updating of the hit-counter file. The C code would then use system-level file locking code such as lock() or flock(). You would use the stand-alone program via a call to java.lang.Runtime.exec(). You would just invoke the Java native method. [See above for information about how to write native methods.]

Well, heretically speaking, in the particular case for which you want to use Java, I would just use some existing, well-tested, freely available Perl code to maintain the access counter. For existing Java solutions, see the previous question.

Asynchronous applet class loading?

Billy Quinn asks: I was wondering if you know of any way of preventing Java from loading all of the classes while an applet is being loaded, as opposed to loading the classes as you need them dynamically.

Well, I do not know of any tricks to do this for normal situations. You could probably write your own class loader but that would not be a good general solution since you can't control the class loader used by the browsers of folks using your applet.

Socket security exception

Tom O'Shea asks: When an applet on my server tries to connect to my mail host to send a message under Netscape 2.0, I keep getting this message:

#Security Exception: Socket.connect: "server name" -> "mail host name"

This is most likely due to the security restrictions in the Netscape browser. The security manager does not allow the applet to connect to any host other than the one from which it was retrieved. So, you need to make your applet use the mail system on your Web server instead.

Tom also notes: It works fine when running under Symantec Cafe Applet Browser.

That is not surprising. The various applet viewers/browsers are basically developer tools and therefore tend to be the most lenient on security issues. For information on the security policy of a specific browser, you should also check out the browser documentation. Alas, that documentation is not always all that helpful. The comp.lang.java.security newsgroup is a good resource on Java security.

Inter-applet communication update

A quick update on the inter-applet communication update from last month. The static data member "trick" that was used to communicate between applets is valid. The issue for Netscape revolved around some security problems with the old, relatively loose definition of how the different classes would be able to interact. Netscape in particular will be making this "trick" work again but with some constraints to make things reasonably secure.

Subsisting on caffeine, sugar, and too little sleep, John D. Mitchell has been consulting for most of the last nine years, and developed PDA software in OO assembly language at Geoworks. He funds his Java addiction by writing compilers, Tcl/Tk, C++, and Java systems. He co-authored the hot new Java book Making Sense of Java and is currently developing a Java compiler.

Learn more about this topic

Related: