##### Last modified 04/29/97

# Frequently Asked Questions - Applet Security

The goal for the JDK is to enable browsers to run untrusted applets in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent applets from inspecting or changing files on the client file system. Also, the intent is to prevent applets from using network connections to circumvent file protections or people's expectations of privacy.

JDK 1.1 provides the basic technology for loading and authenticating signed classes. This enables browsers to run trusted applets in a trusted environment. This does not make obselete the need to run untrusted applets in a secure way. In the release following JDK 1.1, we will provide tools for finer-grained control of flexible security policies.

## Status of all known security-related bugs

JDK 1.1.1 Signing Flaw, (April 29, 1997)
  The Secure Internet Programming team at Princeton University notified JavaSoft of a flaw in the way the Java runtime manages identities of signers. JavaSoft is testing the fix and plans to ship it to licensees within 48 hours. Full details here.

Privacy hole, related to IP addresses, fixed in May 1996 JDK 1.0.2 (March 17, 1997)
  Recently we've been getting lots of inquires about an alleged privacy attack on the Java sandbox. The privacy attack is that an applet calls getLocalHost() to find out the IP address of the computer that it's running on. This is not a big deal on the open internet, since IP addresses are clearly well-known and publicized in the internet routing tables. But if the computer running the applet resides inside a firewall, the IP address should remain hidden from the visiting applet. This is exactly what was implemented at JavaSoft about a year go, in time for the May 1996 JDK 1.0.2 release. An applet that calls getLocalHost() will get the loopback host ("localhost/127.0.0.1") as an answer. This is a generic handle to the local computer, which does not reveal any private information that should remain private.

Fix Delivered for Virtual Machine bug (March 5, 1997)
  As part of our ongoing internal security audit at JavaSoft, our engineering team came across a bug in the implementation of the verifier in the Java Virtual Machine.

  Within 24 hours, we investigated the bug and evaluated a fix. We tested the fix and created a patch for our licensees. As we always do, we notified our licensees and shipped the patch immediately. We encourage each of our licensees to include the patch in their products as soon as possible.

  We are aware of no actual attacks involving this bug. It is important to note that a program written in the Java language and compiled by a standard compiler cannot access or exploit this bug. This depends on someone hand-crafting "evil byte code" and trying to slip it by the verifier. The theoretical attack is complex and extremely difficult to exploit.

Update on Java Security and ActiveX (February 25, 1997)
  We've received lots of inquiries on the recently publicized Chaos Computer Club's theoretical hack into Microsoft's ActiveX. This well-established hacker organization, headquartered in Hamburg, demonstrated on German television how its members could use an ActiveX control to theoretically electronically transfer funds from an individual's bank account without using a personal identification number or a transaction number.

  Executable code on the Internet is a complex security issue. That's why Java was designed from the ground up for complex networked environments, and our basic architecture takes into account using executable code from unknown sources. Check out the rest of this document, Frequently Asked Questions--Java Security, for a full description of the Java applet security model.

  In brief, all Java applets run in a protected space that prohibits access to local disk. Encryption and certification can be used in conjunction with applets to add extra levels of security in trusted or controlled environments--like corporate intranets. JavaSoft has included digital signature capability in the Java Development Kit, JDK 1.1, which shipped February 18, 1997.

  ActiveX uses a different model. Because it allows arbitrary binary code to be executed, a malicious ActiveX component can be written to remove or alter files on the user's local disk or to make connections to other computers without the knowledge or approval of the user. There is also the risk that a well-behaved ActiveX component could have a virus attached to it. Unfortunately, viruses can be encrypted just as easily as ordinary code.

  In some cases, digital signing is adequate. In cases where stronger protection is required, Java allows the alternative of running untrusted code securely, which is extremely important for the Internet.

  The most complete security solution for complex networks like the Internet requires not a single security solution, but many. Unlike ActiveX, Java was designed from the ground up for secure network computing. Security is fundamental to Java, not bolted on.

Web Spoofing (December, 1996)
  The Secure Internet Programming team at Princeton University published a technical report describing an Internet security attack they name web spoofing. In this scenario, an attacker

  - creates a shadow copy of a web page
  - funnels all access to the web page through the attacker's machine
  - tricks the unwary consumer into revealing sensitive or private data, such as PIN numbers, credit card numbers or bank account numbers

  Web spoofing requires that the attacker be able to interpose his machine between the server and client, in a man-in-the-middle attack.

  Web spoofing does not require and does not exploit Java technologies.

  If consumers are using a browser that does not have JavaScript (LiveScript) enabled, they will be able to tell that they are being spoofed when they notice either of these visual cues in the browser status line:

  - When a connection is made, the status line shows which host the browser is connecting.
  - When you hold the mouse over a link, the address you will be taken to when you click on the link is displayed in the status line.

  If consumers use a browser with JavaScript (LiveScript) enabled, then even these rudimentary and subtle alerts can be hidden by a malicious script. Recall that such scripts are not written in Java, and are not subject to the Java security model. In that case, consumers would have no way of noticing the spoofing. For this reason, people concerned about web spoofing attacks might consider disabling scripting languages.

  Note that in any case, some novice internet consumers will not be sensitive to visual cues, even if they aren't obliterated by scripting languages. However, it is often the case on the internet that web spoofing attacks are noticed quickly and given wide publicity. Given the nature of the web and how quickly email bounces around the net, there is strong likelihood that a spoofed web site will be found out quickly and publicized widely.

JDK 1.1 beta (December 13, 1996)
  JDK 1.1 Beta 2 fixes the implementation inconsistency in the javakey security tool that caused jar files to be signed with invalid signatures. In JDK 1.1 Beta 1, signature checking always failed, and so all applets ran as untrusted, with minimal permissions enabled. This made the code signing feature unusable, but was not a security hole.

  Please report anything else you find to http://java.sun.com/products/JDK/1.1/bugreport.html.

Illegal type cast attack (June 2, 1996)
  David Hopwood, a Java researcher in the UK, has uncovered a way to manipulate the way objects are assigned and the way they collaborate, in order to undermine the Java type system. Hopwood contacted JavaSoft directly regarding the bug, and we have had a team working on a fix from the time that we were notified. We are also applying Hopwood's model to conduct a security review, to determine if there are other bugs that may apply. Fixed in JDK 1.1; fixes propagated to all Java licensees by mid-June 1996

New twist on previous classloader attack (May 18, 1996)
  The May 18 edition of the New York Times reported that Ed Felten, Drew Dean and Dan Wallach of Princeton University's Safe Internet have found a new way to get past system restrictions on creating a classloader. This attack builds on work done by Tom Cargill. The applet sandbox security model states that applets are not allowed to create and use classloaders to define classes. Once an applet has its own classloader, it can use it to define and execute classes that would otherwise be barred from execution. Fixed in JDK 1.0.2, and in Netscape Navigator 3.0b4.

Hostile Applets (April, 1996)
  A number of hostile web pages, that host malicious or rude resource-consuming applets, are popping up on the web. These sites demonstrate problems related to denial of service attacks. We are investigating ways to better monitor and control resource consumption of applets. Here are more details.

URL name resolution attack (April, 1996)
  For a specific firewall-protected network configuration, an applet downloaded from a client inside the firewall would be able to connect to a single specific host behind the firewall. (It requires an unusual network configuration, but here are the details.) Fixed in JDK 1.0.2 and in Netscape Navigator 2.02.

Verifier implementation bug (Mar, 1996)
  Researchers at Princeton found an implementation bug in the Java bytecode verifier. The verifier is a part of Java's runtime system which checks that applets downloaded over the Internet adhere to Java's language safery rules. Here's our response. Fixed in JDK 1.0.2 and in Netscape Navigator 2.02.

Class loader implementation bug (Mar, 1996)
  David Hopwood at Oxford University found a bug in the class loader that could be exploited to load illegal byte code, which could then be used to load a class referenced by an absolute path name. Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.

DNS attack (Feb, 1996)
  Drew Dean, Ed Felten and Dan Wallach from Princeton described an attack on the applet security model, based on exploiting how the applet security manager uses DNS for name/IP address resolution. Sun's response to this security bug was posted to comp.lang.java on Feb 21. Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.

  Steve Gibbons also independently suggested this attack scenario: see http://www.aztech.net/~steve/java/

JavaScript (Feb, 1996)
  JavaScript is a scripting language used with Netscape Navigator 2.0. There have been reports of privacy problems with JavaScript, and Netscape is committed to addressing those concerns. JavaScript cannot be used to invoke Java applets. The privacy problems reported with JavaScript are not present in Java applets.

## Applet Security

Applets

1. What are applets prevented from doing?
2. Can applets read or write files?
3. How do I let an applet read a file?
4. How do I let an applet write a file?
5. What system properties can be read by applets, and how?
6. How do I hide system properties that applets are allowed to read by default?
7. How can I allow applets to read system properties that they aren't allowed to read by default?
8. How can an applet open a network connection to a computer on the internet?
9. How can an applet open a network connection to its originating host?
10. How can an applet maintain persistent state?
11. Can an applet start another program running on the client?
12. What features of the Java language help people build secure applets?
13. What is the difference between applets loaded over the net, and applets loaded via the file system?
14. What's the applet class loader, and what does it buy me?
15. What's the applet security manager, and what does it buy me?
16. Is there a summary of applet capabilities?
17. If other languages are compiled to Java bytecodes, how does that affect the applet security model?

Examples
  Tiny applet examples that demonstrate the security features of your web browser.
Glossary
  Terms used in this FAQ.
See Also
  Other references on Java security

## Applets

1. What are applets prevented from doing?

   In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.

   In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.

   There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.

2. Can applets read or write files?

   In Java-enabled browsers, applets cannot read or write files at all.

   Sun's appletviewer allows applets to read files that reside in directories on the access control lists.

   If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot

   - check for the existence of the file
   - read the file
   - write the file
   - rename the file
   - create a directory on the client file system
   - list the files in this file (as if it were a directory)
   - check the file's type
   - check the timestamp when the file was last modified
   - check the file's size

3. How do I let an applet read a file?

   Applets loaded into a Java-enabled browser can't read files.

   Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the `acl.read` property in your `~/.hotjava/properties` file.

   > Note: The "`~`" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your `F:\` drive on your PC, and create a top-level directory named `.hotjava`, then your properties file is found in `F:\.hotjava\properties`.

   For example, to allow any files in the directory `home/me` to be read by applets loaded into the appletviewer, add this line to your `~/.hotjava/properties` file.

       	acl.read=/home/me

   You can specify one file to be read:

       	acl.read=/home/me/somedir/somefile

   Use ":" to separate entries:

       	acl.read=/home/foo:/home/me/somedir/somefile

   Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.

4. How do I let an applet write a file?

   Applets loaded into a Java-enabled browser can't write files.

   Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.

   You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file:

       	acl.write=/tmp

   You can allow applets to write to a particular file by naming it explicitly:

       	acl.write=/home/me/somedir/somefile

   Use : to separate entries:

       	acl.write=/tmp:/home/me/somedir/somefile

   Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.

5. What system properties can be read by applets, and how?

   In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking `System.getProperty(String key)`:

         key			meaning
         ____________		______________________________
         java.version		Java version number
         java.vendor		Java vendor-specific string
         java.vendor.url	Java vendor URL
         java.class.version	Java class version number
         os.name		Operating system name
         os.arch		Operating system architecture
         os.version	        Operating system version
         file.separator	File separator (eg, "/")
         path.separator	Path separator (eg, ":")
         line.separator	Line separator

   Applets are prevented from reading these system properties:

         key			meaning
         ____________		_____________________________
         java.home		Java installation directory
         java.class.path	Java classpath
         user.name		User account name
         user.home		User home directory
         user.dir		User's current working directory

   To read a system property from within an applet, simply invoke `System.getProperty(key)` on the property you are interested in.

   For example,

         String s = System.getProperty("os.name");

6. How do I hide system properties that applets are allowed to read by default?

   There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the `~/.hotjava/properties` file.

   From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your `~/.hotjava/properties` file. For example, to hide the name of the operating system that you are using, add this line to your `~/.hotjava/properties` file:

       	os.name=null

7. How can I allow applets to read system properties that they aren't allowed to read by default?

   There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default.

   To allow applets loaded into the appletviewer to read the property named by `key`, add the property `key.applet=true` to your `~/.hotjava/property` file. For example, to allow applets to record your user name, add this line to your `~/.hotjava/properties` file:

       	user.name.applet=true

8. How can an applet open a network connection to a computer on the internet?

   Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the `codebase` parameter in the `applet` tag, with `codebase` taking precendence.

   For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:

       	Socket s = new Socket("foo.com", 25, true);

9. How can an applet open a network connection to its originating host?

   Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.

   That is, if you load an HTML page using the URL

       	http://foo.state.edu/~me/appletPage.html

   then your applet will be able to connect to its host only by using the name `foo.state.edu`. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work.

10. How can an applet maintain persistent state?

    There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.

    Interesting examples are

    - Chat Touring, by Paul Burchard
    - Scribble Forum, a shared scribble pad, by Robert O'Callahan

11. Can an applet start another program on the client?

    No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.

12. What features of the Java language help people build secure applets?

    - Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application.

    - C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures.

    - Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes.

    - Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the `String` class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets.

    - The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check.

    - The `final` modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify `final` variables.

    - Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example, invoking

            t.currentThread()

      when `t` is not a `Thread` object causes a compile time error.

    - Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated.
      - public: a public method is accessible anywhere the class name is accessible
      - protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class. For example,

              class Parent { protected int x; }
              class Child extends Parent { ... }

        The class `Child` can access the field "`x`" only on objects that are of type `Child` (or a subset of `Child`.)

      - private: a private method is accessible only within its defining class
      - default: if no modifier is specified, then by default, a method is accessible only within its defining package

      For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.

13. What is the difference between applets loaded over the net and applets loaded via the file system?

    There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.

    If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.

    If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are

    - applets loaded via the file system are allowed to read and write files
    - applets loaded via the file system are allowed to load libraries on the client
    - applets loaded via the file system are allowed to exec processes
    - applets loaded via the file system are allowed to exit the virtual machine
    - applets loaded via the file system are not passed through the byte code verifier

    Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs.

    This means that if you specify the URL like so:

        	Location:  file:/home/me/public_html/something.html

    and the file something.html contains an applet, the browser loads it using its applet class loader.

14. What's the applet class loader, and what does it buy me?

    Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.

    The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.

    Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that

    - There are no stack overflows or underflows.
    - All register accesses and stores are valid.
    - The parameters to all bytecode instructions are correct.
    - There is no illegal data conversion.

    The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of `finally` clauses that are used for Java exception handling.

    Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.

    A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.

15. What's the applet security manager, and what does it buy me?

    The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.

    A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.

16. Is there a summary of applet capabilities?

    The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.

    Key:

    - NN: Netscape Navigator 2.x, loading applets over the Net
    - NL: Netscape Navigator 2.x, loading applets from the Local file system
    - AN: Appletviewer, JDK 1.x, loading applets over the Net
    - AL: Appletviewer, JDK 1.x, loading applets from the Local file system
    - JS: Java Standalone applications

        		 Stricter ------------------------> Less strict

        			NN	NL	AN	AL	JS

        read file in /home/me,	no	no	no      yes     yes
        acl.read=null

        read file in /home/me,	no	no	yes	yes	yes
        acl.read=/home/me

        write file in /tmp,	no	no	no	yes	yes
        acl.write=null

        write file in /tmp,	no	no	yes	yes 	yes
        acl.write=/tmp

        get file info,		no	no	no	yes	yes
        acl.read=null
        acl.write=null

        get file info,		no	no	yes	yes	yes
        acl.read=/home/me
        acl.write=/tmp

        delete file,		no	no	no	no	yes
        using File.delete()

        delete file, 		no	no	no	yes 	yes
        using exec /usr/bin/rm

        read the user.name	no	yes	no	yes	yes
        property

        connect to port		no	yes	no	yes	yes
        on client

        connect to port		no	yes	no	yes	yes
        on 3rd host

        load library		no	yes	no	yes	yes

        exit(-1)		no	no	no 	yes	yes

        create a popup		no	yes	no	yes	yes
        window without
        a warning

17. If other languages are compiled to Java bytecodes, how does that affect the applet security model?

    The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation.

### Examples

None of these examples are malicious - the one line descriptions can be taken at face value. You can look at the source code for each applet, before visiting the page that has that applet inside. (The first link in each example takes you to the source code, and the second link takes you to an html page that includes the executable content for the example.)

Files:

- Can this applet read files on your system?
- Can this applet obtain information about files on your system?
- Can this applet write a file on your system?
- Can this applet use File.delete() to delete the file named /tmp/foo?
- Can this applet use the unix command /bin/rm to delete the file named /tmp/foo?

System Properties:

- Can this applet read the ten system properties that applets are allowed to read by default?
- Can this applet read hidden properties like `user.name` or `user.home`?
- Can this applet replace your browser's property file?

Sockets:

- Can this applet connect to port 25 on www.netscape.com?
- Can this applet send data to www.sun.com?

Processes:

- Can this applet kill your browser?
- Can this applet run some program on your computer?

Libraries and name spaces:

- Can this applet load a library on your computer?
- Can this applet create its own class loader?
- This applet tries to create a class of its own in the java.net namespace, but it can't. This example will not compile with the Java compilers that conform to the Java language specification.

Windows:

- What does a window created by an applet look like?

## Glossary of terms used in this FAQ

Applet
  A Java program that is run from inside a web browser. The html page loaded into the web browser contains an `<applet>` tag, which tells the browser where to find the Java .class files. For example,

      	appletviewer http://foo.com/~jo/coolApplet.html

Standalone Java application
  A Java program that is run by invoking the `java` interpreter. For example,

      	java coolApplication

Server
  The computer that hosts the web page that contains an applet. The .class files that make up the applet, and the .html files that reference the applet, reside on the server. When someone on the internet connects to a web page that contains an applet, the server delivers the .class files over the internet to the client that made the request.

  The server is also known as the originating host.

Client
  The computer that displays the web page that contains an applet.

  The terms server and client are sometimes used to refer to computers, and are sometimes used to refer to computer programs. For example, www.sun.com is a server, and the httpd process running on www.sun.com is its server process. My computer at home is a client, and the web browser running on my computer at home acts as the client process.

## See Also

Low-level Security in Java, Frank Yellin, WWW4 Conference, December, 1995
  This paper presents the details of the lowest levels of the java security mechanism. Before any downloaded code is executed, it is scanned and verified to ensure that it conforms to the specifications of the virtual machine.

HotJava: The Security Story
  This paper from May 1995 (the 1.0alpha3 release of Java and HotJava) provides a high-level overview of the security mechanisms, which were elaborated on for the JDK 1.0 release.

Copyright © 1996 Sun Microsystems, Inc., 2550 Garcia Ave., Mtn. View, CA 94043-1100 USA. All rights reserved. Contact the Java developer community via the newsgroup comp.lang.java or JavaSoft technical support via email to email addresses. Send questions or comments about this web site to
webmaster@java.sun.com.