AUUG: Victorian Chapter - Chapter Technical Conference





Embedding Java

Enno Davids
Enno.Davids@metva.com.au





Abstract

Since the eariest days of the net, when spare hardware at CMU was used to make the local Coke machine a network participant, the desire to network enable everyday devices has been strong. Many such proprietary interfaces have been created, and many existing protocols have been suborned to the task of allowing network control over devices which have not offered such interfaces to this point in time. Java and its close relationship to the Web now offers to make the interface problem almost irrelevant. The questions which remain are: what is necessary to support Embedded Java.

Introduction

Many devices are daily being attached to networks which are no longer the traditional networking devices. Rather than being the hosts or routers we are now faced with a world in which network enabled devices are making their presence felt.

While the hosts we attach to networks are well catered for by the various protocol families, most netework devices are poorly serviced if at all by the mainstream network protocols. This is in spite of the fact that anecdotally at least, the desire to network attach a wider variety of machines dates back to the very earliest days of the net.

As a result, until recently, such network attached devices were limited to routers and bridges, printers and the occasional piece of more exotic hardware. For the network building hardware, like routers, a special protocol, namely SNMP, was defined to enable remote reporting and configuration of the device. For many other devices, SNMP has been adopted as a lowest common (control) denominator. In most cases it offers a control paradigm which only poorly matches the needs of the device in question. Even the devices for which it was designed, fall back to telnet as their primary configuration method (i.e. the administrator uses the ubiquious telnet program to establish somthing which behaves like a host terminal session with the device being controlled).

Moreover, for those organisations offering services across a network, the interfaces available were all almost completely proprietary. The arrival of the Web has at least ameliorated the situation for those who can make do with a simple forms based interface, but were a richer interface paradigm to be available, a competitive, commercial organisation would be almost certain to adopt it. Enter Java.

A brief history of Networked Devices

A brief reprise of the history of network control of devices can let us see the playing field onto which Java is now being thrust. As has been mentioned, the earliest recorded instance of the network being invaded by a device with no real need to be networked was the Coke machine at CMU. This otherwise normal Coca Cola vending machine was 'enhanced' by the local caffeine addicts in such a manner that it could be remotely polled for the status of the drink stacks from any network host. In fact, this has become something of a popular game these days with many Coke vending machines around the world kitted out in this manner. The key quetions was, "How to make the data available to as wide a possible user community?" The answer chosen was to use the finger(1) program/protocol to carry the data. For some idea of what this looks like, I have inluded the output from a machine at the University of WA below:

Finger(1) is a reasonably clean interface as it is both simple and widely available. Newer variations on this theme are FTP, gopher and of course Web interfaces. The chief drawback is generally that (with the exception of FTP) read-only interfaces are most easily catered for.

The next step was the development of a long line of incompatible, proprietary interfaces by various different commercial (usually hardware) vendors. The designers of these interfaces have chafed against the chief difficulty which arises from making use of an existing protocol. This is of course that, the model of the protocol will impose natural limits on the services which can be offered. This is to say, if we use FTP, everything must look like a file transfer, if we use finger, everything must look like an enquiry about a users life decisions, and so on. By building a completely proprietary interface, these limits are circumvented. The interface can now offer whatever it is wished it should be able to. The cost is that a matching proprietary User Interface program must be offered. The wide variety of hardware and operating system combinations then works to ensure that the vendor has a significant task attempting to cover their market (The alternative of only offering a few selected platforms is also vigorously pursued, especially by those who believe that the modern computing world finishes where PC's do.)

It is worth noting that proprietary may or may not also mean secret. Examples of both are common. For instance, Sun's Network Manager product makes use of a proprietary, but published, interface built on top of their ONC RPC mechanism. This is in contrast to the many secret control interfaces which exist in the world. Of these some are secret for commercial adavntage and some are secret merely because there is no real need nor interest in having them published.

The natural solution to the headache of everyone having their own protocol is to define one for everyone to use. SNMP is the most recent of a number of such protocols. SNMP - the Simple (misnomer) Network Management Protocol - is a general, extensible means for interoperable equipment and management software to exchange data and instructions. So, in theory, SNMP by having some degree of support from all parties, should have addressed everything that irritated us about generic and proprietary interfaces.

As you might expect, not quite. As with most standards, SNMP suffers from a number of shortcomings. The first is one which all such standards must deal with. In the attempt to be all things to all users, SNMP has to a greater or lesser degree inconvenienced all the members of this same community. SNMP's difficulties are chiefly:

Java

Java enters the scene only indirectly. To see what it can and can't do it is instructive to briefly look at its roots. Java has a slightly chequered history and in some ways may still bear the scars of this history.

In the Northern Spring of 1990 a small group of disaffected engineers inside Sun were given the go ahead to work on developing a next generation of user interfaces for everyday appliances aimed at being useful to non-computer professionals. By 1991, the group had physically moved from the main Sun corporate campus to their own site. This was possibly principally pyschological move intended to distance the group from the mainstream of Sun corporate management and as they saw it interference.

By late 1991, the group now called 'Green', had identified the need for a strong 'industrial-strength' OO based language to push their ideas further. This language, named Oak internally, was developed by James Gosling for the group. A Graphical environment is designed which will become the core project of the Green team. The group now believes it should build 'an interface to cyberspace' or 'a visual gateway into the virtual world'. By late 1992, a working prototype (the *7) of the new concept is demonstrated to senior Sun managers and is well received by them. The UI is a breakthrough for the time and Sun spins out a separate company, FirstPerson Inc., to make the attempt to find buyers for this technology.

In 1993 FirstPerson deals with Mitsubishi and French Telecom as well as unsuccessfully bidding an Oak interface to Time-Warner for set top boxes (i.e. cable TV/Video on demand decoders & controllers) and to 3DO. By early 1994, FirstPerson is scrapped and Oak is to be redeveloped for the Internet. In particular, mosaic has by now been released and has started the exponential growth of the Web.

By early 1995, Oak has been renamed Java, HotJava the Web browser has been written in it and the Web has become a major piece of the computing landscape. Almost single handedly, the Web is now attracting millions of non-computer geek users and the demand for interfaces which are more than the static documents, which were all that the original academic progenitors of the Web had forseen, was strengthening. Enter a programming language which has been tailored to run in a Web browser, Java.

All of this by itself would have made Java just another programming language. The key ingredient now was that Java was tailored to run in the Web browsers of the users. To do this it must of necessity have a few interesting features.

Java, is at its heart an interpreted language. To regain some efficiency, Java is precompiled into a machine neutral form called `bytecodes' in the jargon of Java and these bytecodes are then interpreted by a Java Virtual Machine (JVM). Those of you who can remember far enough back to the heady days of UCSD Pascal may remember a similar scheme of compiling to P-codes and having an interpreter which executed the P-codes. In fact, the JVM was modelled on the earlier P-code architectures in some places. The JVM in fact implements a fairly simple stack based architecture for which the Java code is compiled. [It is interesting to note that at least one implementation of hardware, The Western Digital MicroEngine, was made in the old days which could directly execute the UCSD P-codes. It is a matter of current speculation as to whether similar hardware can be built for Java. Given the historical precedent, it would seem that the answer should be yes.] It should be noted of course that there is nothing preventing the intermediate bytecodes from being further processed to produce real machine code for a target environment. Indeed, tools to do this are distributed. It should also be noted that there is nothing to prevent other languages from being compiled into bytecodes for the JVM to execute. The JVM has in fact taken the place of the target hardware. The only real difference is that the single definition of JVM runs on the many real target architectures.

The key here is that the JVM allows programs to be distributed which are not tied to a single make of computer, model of CPU, or flavour of operation system software. For an environment like the Web this could be crucial. For the rest of us, it will certainly be nice to have.

The JVM model of the language also allows significant amounts of checking to be built in the interpreter loop. Some of these checks are simple runtime tests for common programming errors and some are checks for violation of security policies. Java in fact attempts to enforce strict measures of the codes (applets) which it runs to prevent the possibility of rogue programs causing damage or distress. The degree to which this will succeed remains an open question, but it certainly appears the the will to correct any flaws as they are found is at least in place (which we know because a flaw was recently found).

Java is, as are most of the latest crop of languages, an Object Oriented one. It is loosely modelled on C++ although in some areas conscious decisions have been made to jettison C++ features which were felt undesirable. For example, unlike C++ Java only supports single inheritance and does not allow overloading of operators. It does however allow overloading of methods inside classes. The balance which was struck obviously represents one which the designers felt was best at the time. In the long term it remains to be seen how successful this is. Other C++ features which were retained are the exception mechanism for trapping and handling or passing off error conditions.

Other features which are new to Java are more interesting. Java pointers are more like those of Pascal then those of traditional C. In addition to this, Java pointers are never freed. Instead a garbage collector is used to reap objects which are no longer in use by anyone The intention here is to prevent the `memory leaks' which plague many modern projects. The garbage collection mechanism is also said to have benefitted from the research which has occurred since the last mainstream languages which made use of it were proposed in the 60's and 70's.

Like many other languages Java offers access to the thread mechanism which many host operating systems can now offer. Unlike most, it also attempts to offer native synchronization and mutual exclusion of threads from critical areas of code without the need for much programmer effort. This as you may realize is an attempt to make the use of threads less prone to the sorts of errors which can occasionally plague program using these facilities.

5 minute intro to Java

Java is in some sense a classic structured scoped 3GL. In addittion to this it offers OO features such as single inheritance and method overloading. Like many modern languages, its base syntax is quite straightforward while much of the versatility and flexibility of the language comes from the library or more correctly in this case, from the base classes which are provided for the user to make use of.

Rather than belabour the similarities or differences, let's just have a quick look at some Java code. This piece is from some of the example code which comes with the Java Developers Kit.

To those of you with a working knowledge of C or C++ most of this will not look at all unusual. In this respect, Java has few surprises for the working C/C++ programmer. There are a few things which bear explaining. On line 10 you can see that Java allows variable declarations to appear anywhere. On line 11 a method in another class is being called. Lines 9 and 15 through 18 show expressions which most C compilers would be happy with. On Line 7 a new instance of a class (an object) is created.

More interesting perhaps is an example of how we can layout objects on a page for the user to interact with.

This example shows how we can get some GUI objects to render on the screen and in fact also wires them up to do something semi useful. The size of this example compares favorably with many of the newer PC based programming environments and the reader can perhaps see how this could even be generalized into an 5-10 line hello world program. The real message here is that Java programs do not have to suffer from the daunting complexity which characterizes some languages and environments. In spite of this, the base classes offer sufficient flexibility to allow a number of complex tasks to be undertaken easily.

A quick survey of these class libraries is:

These facilities together allow the Applet programmer to make use of most of the facilities of client and server machines and to interact with the user in a richer manner.

Embedding a Java interface

The first question we might consider is where we might choose to embed a Java interface. In fact, my chief interest in this paper is in an embedded system. It is also clear that Java can be used as a User Interface paradigm for basically any service or subsystem which is accessible from outside. Any of the distributed client/server systems with which the industry busies itself can be a target for such a solution. Rather than investing in a UI program written to the constraints of a PC operating system and then later baulking at the retargetting costs when newer but incompatible technologies arrive, Java now offers the solution of the target independant UI with an interface which is built to match the server it comes from. Different servers can offer different interfaces as each will offer its own UI to access it. The same is true for the embedded system about which this paper was ostensibly written.

So the question now becomes what is necessary to embed a Java interface into a device, or a service. The answer depends on where the Java is intended to run. This highlights a point not yet made. The Java runtime environment can exist outside the browser. In this mode, Java is just another language in which to implement programmatic solutions to problems. While implementing a server in Java is indeed feasable, we are not really interested in this mode of operation as things currently stand. The single, unique feature of Java is that it is able to run in a Web browser. This means we fundamentally are interested in Java as a browser based client and not any of the other possible modes of operation.



Supporting Java then becomes a matter of supporting the browser with a HTTP daemon and of supporting the `other` communications channel which Java makes use of. In turn this means that we need some form of tasking, support for multiple TCP sessions, and a file store.

Sizing the components we have identified can let us determine what sort of systems are feasible and what sort need to wait awhile. The components we can readily identify are:

Clearly, the upshot of this is that we will not see light switches, toilet cisterns or electric toasters kitted out with Java interfaces any time soon (thank God). A lower limit would appear to be one of the 16+ bit processors like Intel's higher x86 family members or Motorola`s 683xx embedded processor family.

Clearly also, we will need something like 64kb to 192kb of memory space plus support for the files we will need to serve and room for the application we are actually attempting to interface to. Having seen what our target environment must support, lets have a quick look at what we might accomplish with such hardware and software.

Examples

Two quick examples are presented here. The complete code is presented along with samples of the output. It is also worth noting that unlike the earlier code fragments these examples are complete Java Applets.

'quote' server.

UNIX systems have for some time had the ability to generate canned pieces of what often passes for humor in the computer community. This service(?) can also be made available to users on the network. So the first example I have built is simply a piece of Java to access this service. I have chosen this service as it is a fairly straightforward one and is slightly less boring than the daytime service. The service itself is one of the simple ones where connecting implies a request, which is satisfied and then the peer (server) disconnects. The Java code to do this is as follows:

Most of the early parts of this code deal with things we have looked at before. As such, we will not dwell on them again. The things of interest to us happen in the function fill_text_area() in lines 40 to 61. Even here, things should be reasonably familiar to users of sockets in C. Briefly, in line 45 a socket is opened. In line 46 we make it into a buffered I/O object and then collect the data from it in lines 49-51. The socket in closed in line 52 and the text is formatted and pumped into the text box in line 59.

An example of what this looks like is shown below.

If you can see this text, your browser had some difficulty running the Java program. You can however try the potted GIF file below.

(If you are not running a Java enabled browser, click here to see some sample output.)




AVL data display

The second example is slightly more useful. Some of you will know that I have a financial interest in an AVL (Automatic Vehicle Locating) system. The second example shows how a Java based client program might connect to a central service which distributes the position fixes which the system collects.

Lines 26-85 represent the setup of the display for this example. As we need to deal with mostly automatic layout of the display in the presence of resizable windows, we do not have the luxury of specifying fixed positions for the GUI elements we wish to use. Instead we specify relationships and rules. Users of Tk/tcl will see some similarity with the layout mechanisms deployed there.

Lines 88-112 form the first significant difference in this scheme from any of the other more conventional means of giving Web pages dynamic content (such as using the cgi interface). In these lines we are arranging to spin out Applet out into a separate thread of execution. In effect, we are decoupling the applet from the browser UI in which it is embedded.

Lines 118- 132 form the core of the running applet. This code does little except (re)establish the data connection to the AVL server and then enter a loop to deal with the data as it arrives.

Lines 137-175 forms the core of the service loop. It arranges to read a packet of data from the connection and if the type is 6 (an AVL position fix) it will read the balance of the data, decoding the fields in which it has an interest. If the packet type was one of the other types in which we have no interest (here) then it is skipped.

Lines 157-166 are where the text fields are updated. (Complete with commented code which simply dumps the radian lattitude and longitude values directly). The code mostly uses the final utility function at Lines 180-197 to format the radian value in a slightly more human readable form.

Once again, the output of this applet is shown below.

If you can see this text, your browser had some difficulty running the Java program. You can however try the potted GIF file below.

(If you are not running a Java enabled browser, click here to see some sample output.)




It is also worth briefly considering at the code at the far end of the data connection. In this case, it is a simple RPC style wrapping program which takes the position fix (and other) data and presents it to any clients which connect in an agreed upon format. Most of the problems this Java applet may encounter in fact are likely to revolve around the usual machine dependencies such as byte ordering and packing. In fact, examination of the code will see that packing is unlikely to affect the applet at all. Byte orders will be more important.

Futures

Where Java will head from where it is now is not too clear. What is clear is that it has picked up a large amount of momentum. Many users are now seeing Java as the new model for what the net can provide. To this extent Java may already have gained sufficient momentum to outpace the competitive products being touted by Microsoft and Bell Labs to name just two. Microsoft has already announced plans to incorporate Java into their Web product line and they are not alone as much of the industry is now playing a game of cat and mouse attempting to catch Netscape.

As to the future of the Java language itself, Sun has signalled an intention to retain fairly tight control over the language specification. By way of example, Sun will supply JDK source code free of charge to anyone who wishes provided that they agree to a number of conditions, one of which is that any changes which they wish to promulgate must not alter the core language. If nothing else, this policy will guarantee backwards compatibility. [I should stress here that this is only one of the conditions and not the only condition. Unsurprisingly, the full agreement has some extra clauses you also need to live up to.]

The issues of implementation I touched upon before are also being actively discussed. The nature of the JVM and how close to hardware it may be implemented are of interest here as are the questions of whether we may see other languages implemented as front-ends to the JVM. Ultimately, the JVM is just another machine code. It has some features which allow it to be implemented efficiently in other machines and it has features to enhance the security of the language itself.

Whether James Gosling's future of Java powered light switches and toasters comes true or not is more likely to be a question of ubiquitous computing than whether Java itself succeeds. Java the porgramming language is not without merit. Java the programming language which we can attach to documents on the Web is clearly a new idea. Suns vision of dynamic content and a new generation of video games is only the beginning. The ability to distribute function to the place it is requested and to continue to interact once it is there may signal the beginning of a whole new User Interface paradigm. Servers can now be feature rich, change at will and continue to operate so long as they can supply a downloadable UI (client) for their current functions.

Conclusion

Java clearly offers new opportunities for individuals and organisations who wish to provide control interfaces to hardware they are building or even to services they provide. Java's chief advantage is that the device or service now offers a natural interface of itself rather than needing to rely on a suitable interface existing in the user community for use with it.

Java may in fact cause a resurgence of the proprietary inteface. Now that a machine independant means of servicing such interfaces is available in the form of Java driven extensions to otherwise conventional Web browsers, the cost of mnaintaining such interfaces becomes negligible. In fact, the Java powered interface is now likely to be both cheaper, more ubiquitous and in time more flexible and more useful to the user community. Given the high costs associated with mainstream Network Management packages, Java powered interfaces are likely to be seen as offering superior value to smaller communities of users.

How such Java powered interfaces will fare in the wider world of control, where peripherals are being controlled which have to this point not even had network interfaces, is unsure. Whether Java and its supporting infrastructure can be squeezed to the point where say X-10 and Cebus home control peripherals are targetted remains to be seen. It will almost certainly allow other midrange devices, such as office block climate control systems for instance, to make an appearance on the network to offer better access to the control functions. It would certainly seem to have a place where the resources to support it are available.




Document last revised: March 31st, 1996

Prev Paper

Conference
Programme

Next Paper



Author's papers