Welcome to Java Developer There is much interest in the Java programming language. Our new regular column offers you access to Java experts. By Rinaldo DiGiorgio

November  1995

Java offers many features that make it an applicable language for applications of all kinds. Java's designers built a practical language for distributed computation, while avoiding the complexity found in other languages. This article outlines Java's strengths and features, and offers references to additional information. (See the sidebar to witness a whimsical discussion on Java between four computer legends.) (5,200 words, including sidebar)

Mail this article to a friend

Java is the new language developed by Sun Microsystems that significantly raises the level of technology on the Web. Java allows individuals, Web designers, and organizations large and small to build highly interactive and safe applications. The technology is based on

• true executable content embedded in an extensible language;
• automatic download of applications ("applets") in a safe manner;
• portability by standardizing on a "neutral" architecture;
• client/server functionality on the Internet or "intranet;"
• built-in security that is extensible.

Running some Java applets will demonstrate the above features. For those of you with a mathematical or financial background run the derivative calculator applet at http://zeitgeist.com. For those of you with a consumer preference, there is the multimedia application at http://www.vectorman.com. (If you do not have HotJava and you click on the link, your browser should just ignore the applet.) For those of you using HotJava you have just downloaded a program that can be run on your system. This same program runs on Solaris for SPARC, Solaris for Intel, Windows 95, and NT without modification.

HotJava Alpha 3 is the current release of the browser. Until now, releases contained a browser and interpreter, with its corresponding API. The JDK (Java Development Kit) is the next iteration of the API. The JDK does not contain a browser but does contain an appletviewer, which allows you to view applets for debugging and development, and deployments that use no HTML other than a tag to call an applet. More information on obtaining the JDK is available.

Alpha 3 applets do not work with the JDK or Netscape. Small modifications are required. The procedure for converting an Alpha 3 applet is described in Converting Alpha 3 applets. The HTML interface language was changed slightly, requiring some minor edits to applets. To get an Alpha 3 applet working with the JDK and Netscape you need to convert the applet and modify the HTML file that calls the applet.

At the time of this writing a new Netscape version of a browser that supports Java Applets was not released. To avoid confusion, we will discuss Netscape's Java abilities in the next issue and focus on HotJava this month.

Let the games begin
The HotJava browser reads standard HTML just like any other Web browser. It also has the ability to download Java applets. To accomplish this, a small addition was made to HTML. An additional tag was added (<APPLET>) that allows the specification of a Java applet class to be loaded. When a user clicks on an application that requires an applet, the HotJava browser calls a thread that loads the applet from the network or local filesystem. The code that is loaded is the architecture-neutral bytecodes produced by the Java compiler. These bytecodes are verified and then decoded into machine instructions. It is hoped future versions will compile these bytecodes to native machine instructions for improved performance.

Many languages share some of the features of Java. The Java designers built a practical language for distributed computation without the complexity associated with such languages. Why another language? It can be argued that there are systems with enough ubiquity (consider the proliferation of DOS/Windows 3.x) that there is no need for Java's benefits. Many years ago, Japan launched a project called TRON. The purpose of this project was to provide one OS and one hardware platform for the entire country of Japan. This project ultimately failed. Java, unlike TRON, is based on standards, proven network infrastructure, and is architecture independent at runtime.

The salient features of the Java Language are:

• Object-oriented. Like Smalltalk, everything in Java is an object. Objects are instances of Java classes. One example of a Java class is the Applet class. Classes are created from Java source files with the Java compiler.

• Total Pointer Control. In C and C++, pointers are sometimes too powerful for our own good. Not only are they a common source of programming errors (so common that the VAX used to store at address 0 so that de-referencing a NULL pointer would not be invalid), pointers are also a common source of security violations. In C and C++ for example you can subvert the type-checking system at runtime by explicitly casting the address of a memory area and then getting to a private member causing an undetected access violation. Consider the following example from C++:

  class A { 
  	public	int	amount;
  	private int	total; 
  } 
  
  p = new amount 
  p = p + 4; 	// Find location of private member
  *p = 10000; 
  

  In Java this is not possible. All accesses to memory areas must be done using object instance variables. This feature provides additional security protection against internal security threats -- programmers leaving a Trojan horse that accesses private data. It also provides protection against inadvertent pointer over-run or under-run errors, as well as incorrect offset calculations.

  A typical programming error is introduced by a casting operation. Consider the structure foo defined below. This structure has a couple of useful members -- a name field, and an id field:

  struct foo {
  	char	name[10];
  	int	id;
  }
  

  If this structure was known to your program, you could access any piece of memory as a structure of type foo by simply using this fragment of code:

  struct	foo *a;
  a = (struct foo *)(0x1234);
  printf("user %s, id = %d\n",a->name,a->id);
  

  However if the memory so addressed was not a structure of type foo your results would be unpredictable at best. In Java this is not possible. All accesses to memory areas must be done using object references. When used, these references are checked for type compliance. Loosely typed data structures defined by struct or typedef in C or C++ are replaced with a strongly typed data structure defined by class in Java.

• Automatic garbage collection. Java deallocates and allocates variables and collects garbage on freed memory, or compacts the blocks. The simple process of reassigning or assigning a value to a variable will cause the previous instance of the object to be properly dereferenced, unlike other languages. The actual memory used will also be marked for deletion. Consider this trivial code snippet:

  record = (struct foo *)malloc(sizeof (struct foo)); 
  ... some code
  record = next_record
  

  In C and C++ we would be left with a memory block in the heap without a corresponding pointer. In Java, once this allocated memory was no longer referenced, it would automatically be returned to the heap. In C and C++ you have to perform frees over and over again and keep track of a pointer that is separate from the object in some cases.

  Another advantage is the number of errors that are prevented when one portion of the C code calls free() to return allocated memory to the heap but another portion is still holding pointer to it. If the memory gets re-used the program will crash when the stale pointer is used, sometimes much later in the execution. Problems of this type are hard to debug and often complicated by timing differences and code paths. In Java, a section of memory is not reclaimed until there are no more references to it in the active code.

• Multithreaded. Java supports threads, allowing it to exploit parallel architectures. Programmers can develop programs using a threading abstraction even if the target platform is a uniprocessor.

• Robust exception model. Java has an exception model that attempts to catch all abends (abnormal program ends) while allowing continued execution of non-faulted components.

• Synchronization. Java has built-in synchronization primitives that allow the rapid construction of semaphores without additional function calls and wrappers. A programmer need only declare a method as synchronized to provide serialization of a function call.

  Consider the implementation of routines to add and delete from a queue. The implementation of these routines often involves the addition of locks to prevent access to a data structure that may be in an inconsistent state. When writing multithreaded programs there are often instances when two threads may attempt to access an object. For example, this would occur if two threads access a function that performs a yield statement. In order to prevent inconsistent state a semaphore or lock is often used. Traditional approaches required the implementor to use a semaphore or implementation of some other locking scheme.

  Java provides a reserved word synchronized that automatically guarantees that two or more threads will not be executing the function that has been declared as synchronized. This approach can cause a performance problem if the function that is declared to be synchronized is very large and has many threads waiting to execute other parts of it that need not be synchronized. An example of the use of synchronized for queue manipulation is provided below:

  public boolean synchronized enqueue(Item i){
  	... Implementation
  }
  
  public boolean synchronized enqueue(Item i){
  	... Implementation
  }
  

  Alternatively one can code a lock only around the section of code that needs to be locked. This would allow other callers to execute more code before blocking. For very small functions this overhead may not be worth it:

  public class SomeClass {
  	Lock myLock = new Lock();
  	void someMethod() {
  		myLock.lock();
  		try {
  			StartOperation();
  			ContinueOperation();
  			EndOperation();
  		}
  		finally {
  			myLock.unlock();
  		}
  	}
  }
  

• Architecture Neutral. Java source code is compiled to Java bytes or bytecodes, which are interpreted at runtime and turned into machine instructions. The same bytecodes would run on any platform that supports a Java interpreter. The potential cost savings to software producers are tremendous due to not having to recompile and test on many different platforms. As software producers begin making word processors and spreadsheet programs available, consumers and corporations will not have to buy systems based on which word processor they support. For years users of high-performance workstations could not get simple productivity applications because it was to difficult to maintain a version of the spreadsheet program that worked on so many different systems. With Java, this could all change as applications become written in an object-oriented lingua franca.

Security -- downloading code over the Internet can be safe
There are several layers to the Java security model. These layers build on each other to provide built-in security that can be extended and or modified.

• Ground rules from the language. The Java Language, which was designed to be a safe language, and the Java compiler, which ensures that source code doesn't violate the safety rules.

• Bytecode verification. Bytecodes imported into the runtime engine are put through a verification process to ensure that they obey the language's safety rules. This layer guards against an altered compiler producing code that violates the safety rules. Once the bytecodes pass the verifier we know the following:
  • The code causes no operand stack overflows or underflows; since all objects are known the exact allocation required is known.
  • The types of parameters to all opcodes are known to always be correct; an opcode will not be given the wrong type of argument.
  • No illegal data conversions are done, such as converting integers to pointers. This is detected by the bytecode verifier.
  • Object field accesses are known to be legal.

• Partitioned name spaces. A class loader that ensures classes don't violate name space or access restrictions when they are loaded from the network or the filesystem.

• Security dialog configuration. By default, HotJava loads all applets it encounters, but lets an applet read only those documents on the host that supplied the applet. The HotJava browser provides a security dialog that allows configuration of policy for applet downloading:
  • No access -- disallows any applets from loading any documents via URLs, no matter where they come from. Turns HotJava into a simple passive browser.
  • Applet host -- allows an applet to load documents only from the same place it came from.
  • Firewall -- lets you specify a firewall (a scope of hosts that you are willing to trust). Once you configure this firewall, applets that are inside the firewall can access any documents via URLs, but applets outside the firewall can access only those URLs that are also outside the firewall.
  • Unrestricted -- allows any applet to load any URL.

• Environment variables. Several additional environment variables are supplied, allowing some restrictions to be relaxed:
  • HOTJAVA_READ_PATH -- used to determine where an applet has permission to read a file. Defaults to <hotjava-install-dir>:$HOME/public_html, where <hotjava-install-dir> is where HotJava was installed.
  • HOTJAVA_WRITE_PATH -- used to determine where an applet has permission to write a file. Defaults to NULL.

• The class loader. Look at environment as a set of classes partitioned into disjoint name spaces. This means the same applet on ten different Web sites and in three locations on your local disk has thirteen different unique names. There are unique name spaces for
  • Local filesystem -- same applet in different hierarchies will have a different name.
  • Network source -- an applet or class on another system accessed via HTTP will have a unique name that identifies the network source.

  A common technique for compromising a system is to replace a good program with a doctored copy. Often this cannot be done directly. An indirect approach looks to replace an applet or class in the search path. HotJava always searches for built-in functions in explicit areas. This design limits spoofing since built-ins are always checked first

• Filesystem protection. Protecting the filesystem and network access:
  • File access control lists. Dialog boxes pop up if there is an access violation. The policy is conservative.
  • Network Security Check. When a class is requested that is located at a machine that is outside the firewall, additional security rules can be applied to it. Some users may not want any class to be loaded that is outside the firewall. Other users may only want to allow certain sites and others may want to allow all classes to load inside or outside the firewall. In future articles we will discuss this in greater detail as well as techniques to prevent applet theft and how you can be sure that the applet you are running is the one the trusted programmer intended you to run.

Late-breaking news
While this article was being written the beta API was released. This API is referred to as the JDK -- Java development Kit. The JDK offers many new improvements and new functionality. Two of our favorite additions are the Java Debugger and the Java Applet Viewer. The imaging model has also been changed significantly and offers an excellent graphics foundation that understands various color models as well as the performance issues with loading images over slow lines. We'll discuss these and other parts of the JDK in future columns. In the mean time, additional information on several topics is available below:

• The source for HotJava/Java
• Netscape and Java
• About JDK
• Converting applets
• Online Java course
• Sample applets

Uses for Java
Java will play a key role in defining the infrastructure of the emerging electronic world. We can actually think of several hundred uses for Java. Here are some of the more common:

• Corporate MIS departments begin replacing mission-critical systems for internal use with a Web-based architecture. The corporate backbones evolve into "intranets".
• Legacy applications on mainframes and other computers get Web-based interfaces so printouts are no longer shipped around via snail-mail or e-mail.
• Web-based Java applets interface information from several different legacy systems into understandable Web pages. For example accessing the 3270 to find a database that tells you where a file is. This can become one mouse-click preserving investment and allowing workers to be more productive.
• Replacement of expense reports, time sheets, and other personnel functions with Java applets.
• The automation of factories with thousands of applets with nice readable graphics interfaces tied into a 10,000-node network.
• Access to decision-support systems from a Web interface
• Web access while you watch TV -- the start of interactive TV.

Future columns
In future columns we will discuss:

• Security issues authentication, authorization and how to build it into your applications.
• Good Java programming techniques and style.
• CELLB video example
• Java and CORBA
• GUI programming examples
• Java development environments
• Embedding Java

Next month, we discuss Netscape 2.0, including example applets demonstrating the use of various methods.

Resources

• Derivative calculator applet
  http://zeitgeist.com
• Multimedia Java applet
  http://www.vectorman.com
• Information on obtaining the JDK
  http://java.sun.com/devcorner.html
• Converting Alpha 3 applets
  http://java.sun.com/JDK-prebeta1/converting/
• The source for HotJava/Java
  http://java.sun.com
• Netscape and Java
  http://www.netscape.com/comprod/products/navigator/version_2.0/java_applets/index.html
• Differences between Alpha and Beta versions of Java
  http://java.sun.com/JDK-prebeta1/filesinkit/README
• Converting applets
  http://java.sun.com/JDK-prebeta1/converting
• Online Java course
  http://java.sun.com/progGuide/index.html
• Sample applets
  http://java.sun.com/applets/

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-11-1995/swol-11-java.html
Last modified:

The scene: The neighborhood cyber-style coffee house. Four friends are sitting at a table, having an animated discussion about the new developments in computing. A PC running a popular Web browser is within arm's reach on the next table.

The four friends differ quite a bit in age. They are (from oldest to youngest): Leonardo Fibonacci, Blaise Pascal, Galileo Galilei, and Ada Augusta. They are all reviewing a recent manuscript written by Galileo.

Galileo: Thank you for your comments. My brain swells with delight. I've interspersed my annotations among yours. (He passes out some papers). What time is it? Can I get an espresso?

Ada:: It's early yet. Senta! Four espressos!

Pascal: But Galileo, I still don't understand. Why should I learn yet another computer programming language?

Galileo: You know, the previous languages have not been as productive as we have hoped. (The waiter comes by and serves the espressos. He accidentally spills one on Fibonacci.)

Fibonacci: I will have to find some statistics on this! (All stare and frown at the waiter who rushes off.)

Galileo: I mean to say that Java is a natural evolution of an object-oriented language. I think its a molto-usable version. You should learn it because you will be more productive. (He slowly takes a sip.)

Pascal: Bien sure -- I've heard that before. What new language? I bet you would even say that if you know C++, then learning Java will be quite easy.

Galileo: If you already know C then you need only learn the simple concepts of object oriented design. Writing in Java is fun, and it is easy. There are so many things that can bite you programming in C, especially around pointers, that just aren't an issue in Java. No more memory leaks or memory smashes, no more indexing off the end of an array that you declare with eight elements and use nine. So many things that you don't have to worry about. It lets you concentrate on what you are writing, not so much on how you write it.

Ada:: That pleases me. So Java eliminates a common source of programming bugs?

Galileo: Exactly. But our friend Fibonacci would probably want to enumerate all the other bugs that Java helps avoid. Could you do that?

Fibonacci: Give me a few weeks and a Javatized browser and I'll show you some real good examples. You know, I can clearly show you the C and C++ nature of Java. I think it should be real easy for C and C++ programmers to make the leap into the Java paradise.

Pascal: That's fine for you. I personally never understood C++, and you all know what I think of C. I like structure. Modularity. Do I have to know C? I actually like HTML. Isn't that a language?

Ada:: Oh, don't be so lazy. I even learned C and C++.

Galileo: Actually, last week I met someone who said Java reminded them of Lisp. You remember, there was a cool Lisp dialect in the old days called Flavors. It had methods and objects and mixins. I think it was named after an ice cream. And you know, yesterday I met someone who said that Java reminded them of Ada? (Ada turns red.)

Ada:: But he should learn C.

Pascal: Don't tell me what I should learn! What do you know!

Ada:: I have a famous programming language named after me.

Pascal: So do I. Big deal.

Fibonacci: Well, I guess we should show the advantages of Java for people like Pascal. What do you say, Galileo? Do we need C++?

Galileo: We need more espresso. I like these interactive sessions. It reminds me of the good old days in Pisa.

Fibonacci: Ah, Pisa. Those were the good old days. What a tower!

Galileo: But Leonardo, you were in Pisa 400 years before me!

Fibonacci: Oh. Yeah. Uh.

Ada:: I was in Pisa once. It must have been 200 years after you, Galileo.

Galileo: How time flies.

Pascal: I was never in Pisa. Who needs it. Do they make you learn C in Pisa? Is that why you all love Pisa? And why is interactivity a good thing? what could you do with it?

Galileo: Interactivity has a single selling point in my opinion. People are different so their needs are different. Providing a static form of interaction will be useful or desirable to some segment of the population, but allowing the user's needs and desires to affect the interaction allows you to target a much larger segment of the population. Consider this trivial example:

Lets say I've got a Web page dedicated to the Grateful Dead. OK, its got a group of people interested in it and they will visit my pages and interact with me.

Fibonacci: Cool.

Galileo: Now let's say I've got a Web page dedicated to rock and roll, the band that is "featured" on my page is selected by the user. Now my Web page is attractive to a much larger audience because the individuals in that audience can select the band that they are interested in. Now extend it to "contemporary music" where the user can select style as well as artists. Now my page appeals to country and western aficionados as well as rock and roll fans and reggae fans as well.

This is because the more interactive my pages are, the more they can adapt to being just what you want to see. And the more "you's" come and visit them. Ergo, I am more successful.

Pascal: Agreed. But the functionality you discuss above can be implemented with a tree of HTML links to various sub-pages tailored to particular musical tastes. Java might make accessing those pages a bit more animated, but it doesn't seem to truly demonstrate the raw power of a Javatized Web site's interactivity.

Galileo: Good point, Pascal. Let's think about it some more. I agree that HTML can point you to the links, but you still have to manage all those helper applications. In Java, it is more manageable.

Ada:: Tell him about the instant distribution of applications.

Pascal: Oh, shut up. Why is the instant distribution of applications so special?

Galileo: Actually, this is a key benefit of Java technology. Do you know, Pascal, that corporate America spends billions on software installation and setup?

Fibonacci: It's up there, I am not sure its in the billions.

Galileo: Get the figures next month. Anyway, the average home consumer does not have the desire to keep reinstalling software. (He takes another slow sip on the coffee.)

Distributing new code is very cheap. If the present distribution paradigm is buy install and leave on disk, then the new Java paradigm is to use and discard.

Pascal: Maybe yes, maybe no. I think that it is possible because Java is architecture-neutral. And that is a very very good thing. I remember many times in Paris when this neutrality was crucial for the success of an application. In my time, neutrality makes it possible for the MIS department to concentrate on its mission, that is, giving efficient access to enterprise networking infrastructure without bogging down in the intricacies of all the platforms that happen to use it. Computers become opaque, you have six units of compute power on your desk, and it doesn't matter if the compute power comes in the Apple, Sun, or Windows flavor, as your CIO or MIS person I can deliver an application to your desktop that runs with six units of compute power and gives you access to the manufacturing inventory projections.

Monsieur Galileo, perhaps it may be nice to mention OSF's and other architecture neutral distribution methods and discuss why it failed where Java succeeded?

Galileo: Yes. I think both the immediate distribution and the architecture neutrality of it are worthy of discussion. The examples mentioned above handsomely illustrate these points. appreciating the benefit of immediate distribution is obtained quickly, but fully appreciating what architecture neutrality offers may require some elucidation.

Pascal: But why should I trust those Java applications, those HTML add-ins, those -- as you call them-- Java applets?

Ada:: I told you he should learn C++!

Galileo: Oh, Basta! No. You don't need to know anything about C++ to understand Java applets. You know Pascal, Java Applets are inherently safer as a distribution system than the current infrastructure in most corporations when the Web architecture is used as an internal architecture. This is due to the fact that the applets are bytecode verified. Future enhancements like MD5 will provide support for digitally signed applications.

Fibonacci: I looked at it already. I trust it.

Pascal: Why should anyone trust any executable you just loaded over the network?

Galileo: One of the most common techniques of system compromise today is to gain access to a network server and install a subverted binary on the system. This gives the bad guys access to every client that loads that binary. Java applets on the other hand are designed to be safe, specifically they can't do anything "bad," only the classes that are already installed on your local disk can do that. Think of applets as an expression of what should be done, not the capability to do it. If an applet is compromised, about the worst that can happen is that it can try to lure you into doing something bad, it in itself is unable to.

Fibonacci: As Galileo said, when the ability to digitally sign classes is part of the system, even this avenue will be unavailable to the undesirables.

Pascal: All well and good, but I would like to see some discussion of why the bytecode verification process can be trusted. What exactly is it and why (and how) does it ensure runtime-safe applets?

Fibonacci: Pascal, I could go into specific details about the safety features of the language and the environment if you would like but that would fill a manuscript in itself.

Ada:: I think it would be cool to provide instructive applets demonstrating or refuting aspects of each of these points. For instance, the security of Java applets can be demonstrated, I guess, by attempting to do harm and having the attempt thwarted. The applet in this case might attempt to remove /kernel/UNIX or something.

Fibonacci: I have an example of writing to the disk and trying to remove files and also an example of zapping the bytecodes. It's cool.

Galileo: These are pretty easy to come by. Of course the question becomes how subtle do you want the attack examples to be? For example we can construct a class that accesses a "private" member of another class and tries to export it and see it fail if you'd like.

Pascal: Subtle examples would be grand! I love the class accessing a private member of another class. But can you tell me just what it means?

Galileo: Sure, but not now. It's getting late. I have an important council meeting tomorrow morning. But let's get together next month and we'll go over some of these examples in more detail!

Pascal: Without C++?

Galileo: For you -- no C++. Buona Notte!

(They all get up to leave.)

About the author
Rinaldo S. DiGiorgio works for Sun Microsystems as a Systems Engineer in the New York City office and provides frequent demonstrations of Java Technology. DiGiorgio is currently working on the integration of many technologies into HotJava/Java. Some of these technologies are database connectivity, portfolio management, low-cost video, and analytical applications in the financial and emerging genetics market. DiGiorgio has been using Unix-based operating systems since 1979, when he was deploying Unix solutions in paper mills. He sees HotjJava/Java as the technology to minimize two great cost factors in the computer industry: distribution and code development.