From: www.itworld.com

Welcome to Java Developer

by Rinaldo S. DiGiorgio

October 19, 2001 —

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 (http://java.sun.com/JDK-prebeta1/converting/). 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 -- http://java.sun.com
  
• Netscape and Java -- http://www.netscape.com/comprod/products/navigator/version_2.0/java_appl...
  
• About JDK -- 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/
  

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.

Unix Insider