The origins of Java go back to 1990, when Patrick Naughton announced that he would leave Sun Microsystems in favor of NeXT Computer Inc. To keep him from leaving, Sun gave him permission to work on anything he would like, with some of the best programmers available at the site, one of which was James Gosling. The initial goal of the project, was to create a device that could control everyday consumer appliances through an animated, graphical interface. Gosling's job was to define and implement a programming language suitable for the task. The programming language was named ``Oak''.
When the device prototype was finally ready, Sun failed to convince potential customers to incorporate the device in their products. In 1994, the project was closed. It was then Bill Joy, a Sun co-founder, got the idea of bringing the programming language to the Internet, by letting it extend the capabilities of the World Wide Web. The language itself became the product, instead of just part of a device. Gosling adapted the language, which was now renamed ``Java'', to the Internet, and Naughton wrote ``HotJava'', a Web browser supporting the language. In an attempt to get a hold on the Internet market, Sun decided to give the products away for free. It has later turned out to be a success [70][71].
Java is an object oriented programming language, highly inspired by C++. What separates it from other popular programming languages, is that a program is normally not compiled to machine code for a particular processor and operating system type, but rather to a binary code interpreted by a ``Java Virtual Machine'' (JVM) [72]. This way, a precompiled Java program may be distributed and run on any computer or other device where a Java Virtual Machine is available. Currently, JVMs are typically available as programs for various platforms, but Sun recently announced picoJava, a microprocessor that executes Java byte code directly.
A Java program may be run either as a stand-alone application, or as an applet loaded as Java byte code from some host on the Internet by a Web browser. Applets are programs run by Java capable Web browsers, showing their output and accepting user input from within the browser window. In effect, applets bring full interactivity to the World Wide Web: An information provider may write a Java program that visualizes the information in a suitable way, possibly guided by user input. The applet concept is a major reason for Java's popularity.
Using interpreted code may slow down execution compared to running pure machine code. Java is normally shipped with an extensive class library, the Java Application Programmer's Interface (API) [73], compiled in the host's native language. The class library handles a great range of tasks, such as file and network I/O, user interfaces and windowing, and image processing. If a Java program fully utilizes the library, most of the execution time will be spent in the library code, thus minimizing the loss of speed introduced by using interpreted code.
A programmer may combine Java code with methods
and libraries written in C, and compiled to machine
language. Such methods and libraries are called native
[74]. Native code may be used for speed critical parts of a
program, but it's use breaks one of the main reasons to use Java in
the first place; portability. In the future, JVMs will probably
translate the Java byte code to machine code, either before or while
running the program. Translating the entire program to machine code,
will eliminate the need for using native code to gain speed.
Java applets are embedded within HTML-documents using an APPLET-tag. Figure 4.3 gives a sample of an included Java applet.
Figure 4.3: Example of an APPLET-tag in a
HTML-document.
As for plug-ins and EMBED-tags, WIDTH and HEIGHT -parameters are required for APPLET-tags, setting the size of the subwindow in which the applet runs. Note the use of a PARAM-tag in figure 4.3. Such tags are used to pass parameters to the applet. Applet programmers specifies a set of parameters accepted by the applet, to let users perform appropriate initialization. The ``You're supposed to see an applet here''-text is displayed by browsers not supporting the APPLET-tag.
Figure 4.4: A sample Java applet displaying live video,
run within Netscape Navigator.
Figure 4.4 shows an applet in action, embedded in a
HTML-page viewed using the browser Netscape Navigator. This real-time
applet displays images received from a remote camera. It's
implementation is described in chapter 6 on
page 
.
Downloading and automatically executing programs from anywhere on the Internet, may be a major threat to the security and integrity of the local system. Java applets are thus denied access to the local filesystem, or given access to a separate part where no harm can be done. When creating network connections, applets are only allowed to connect to the local host, or the remote host from which the applet was loaded.
The security restrictions are handled by a special SecurityManager-class, normally subclassed by the browser. Before doing any possibly restricted actions, the methods in the Java class library call the security manager, telling it about the intended action. If the action is not allowed, the SecurityManager throws a SecurityException, aborting the applet [73].
The prohibition to connect to any host on the Internet except the local host or the host from which the applet was loaded, may be troublesome when using Java applets for bringing video to Web pages. The remote Web server may not be the source of the video. There are a couple of ways to circumvent the restriction:
The first alternative may be the simples to implement, but may not always be possible, as the author of the Java applet may not have access to the video providing host. Chapter 6 gives an example of using a proxy as a gateway between a camera grab server and a Java applet.
At present, no classes in the Java API handles coding or decoding of image streams. There are no classes for discrete cosine transform, Huffman coding, bitstreams and other tools for compression, so everything must be built from scratch. Likewise, there is no support for fetching images from a camera connected to the computer. Programming support for cameras using Java only may be tricky, if not impossible, since access to hardware, special code libraries or a server program may be required.
At present, the solution must be to extend the Java library using native code, or to let Java programs talk to external programs providing the lacking functionality. In the future, video handling and communication with camera equipment may be part of the ever growing standard Java library.