readme

来自「《移动Agent技术》一书的所有章节源代码。」· 代码 · 共 845 行 · 第 1/3 页

This release supports use of a class load hook, a native-code function 
called when each class is loaded. A class load hook can modify the 
class data to include profiling or debugging information. 

Support for a class load hook is a temporary feature and is subject to
change. Class load hook support is not part of the Java platform
specification and will not be available in any Sun Java 2 version of 
the JDK software. Sun's Java 2 JDK software includes profiling 
and debugging features that are more powerful and general.

  4.4.1  Configuring a Class Load Hook
  ____________________________________________________________________

  If the environment variable _CLASSLOAD_HOOK is set, its value should 
  be the basename of a native code library.  For example, if the value 
  of _CLASSLOAD_HOOK is "myhook", the runtime looks for a Windows 
  library called myhook.dll. The location of the library depends on the 
  system platform. For example, on Windows, the runtime looks in the 
  bin directory of the Developer Kit installation, then in each 
  directory in the PATH environment variable.

  4.4.2  The Class Load Hook API 
  ____________________________________________________________________

  The class load hook library must export the following function:

    typedef struct {
	unsigned char *class_data;
	int            class_data_len;
	unsigned char *new_class_data;
	int            new_class_data_len;
	void *       (*malloc_f)(int);
    } classload_event;

    void ClassLoadHook(classload_event *);

  The runtime calls ClassLoadHook() after it obtains the class file 
  data but before it constructs the in-memory class representation. 
  ClassLoadHook() is passed the existing class file data (via 
  class_data and class_data_len), and a pointer to a memory allocation 
  function (via malloc_f). ClassLoadHook() should use the memory 
  allocation function to create a new buffer for the modified class file 
  data and return it via new_class_data and new_class_data_len. If 
  ClassLoadHook() chooses not to modify a class, it should set 
  new_class_data to NULL.

  The runtime is responsible for deallocating the modified class file
  data buffer.

5.0  SHIPPING JAVA APPLICATIONS
______________________________________________________________________

A Java application, unlike a Java applet, cannot rely on a Web browser
for installation and runtime services. When you ship a Java
application, your software package will probably consist of the
following parts:

  o  Your own class, resource, and data files.
  o  A runtime environment.
  o  An installation procedure or program.

Microsoft provides (as of January 11, 1999) a free software package, 
the Microsoft Windows Sockets 2.0 Software Development Kit, that 
includes Winsock 2.0. Even if you don't need to upgrade your own system, 
you might want to obtain this kit so you can ship network applications 
on Windows 95 systems. This free software can be downloaded from the 
following addresses:

  o  http://www.microsoft.com/win32dev/netwrk/winsock2/ws295sdk.html
  o  ftp://ftp.microsoft.com/bussys/WinSock/winsock2/

5.1  Including a Runtime Environment
______________________________________________________________________

To run your application, a user needs a JVM, the Java platform core 
classes, and various support programs and files. This collection of 
software is known as a runtime environment. The Developer Kit software 
serves as a runtime environment. However, you should not assume that 
your users have the Developer Kit software installed. 

Your Developer Kit software license does not allow you to redistribute 
the Developer Kit software files. The Java Runtime Environment 
for Win32 is available for redistribution, with international support, 
as a separate package. 
   
5.2  Installing an Application 
______________________________________________________________________

The final step in the shipping process occurs when the software is
installed onto an individual user's system, the user's system 
is configured to support that software, and the runtime environment 
is configured.

If you use the Java Runtime Environment, you must make sure that your
installation procedure does not overwrite an existing installation,
unless the existing Java Runtime Environment is an older version.

A simple way to redistribute the Java Runtime Environment is to include 
this executable file in your software package. You can then have your 
installation program run the executable 
file, or simply instruct the user to install the Java Runtime Environment
before installing the rest of your package.

A more sophisticated approach is to install the Java Runtime
Environment on your own system, then copy the files you need into your
own installation set. If you choose this approach, you must include all
files described as "required" in the Java Runtime Environment README.
The Java Runtime Environment software can only be redistributed if all
"required" files are included.

If you use this approach, do not try to emulate the installation steps
performed by the Java Runtime Environment installer. You might break
an existing Java Runtime Environment installation by missing a new or
undocumented installation step. Instead, you should include the Java
Runtime Environment files in your own application directory. In effect,
your application has its own private copy of the Java Runtime
Environment.

  Note:  The installation program records program information in 
         the Windows Registry. This registry information includes the 
         software version, which you should compare with the Java 
         Runtime Environment version in your software package.

6.0  TROUBLESHOOTING
______________________________________________________________________

Here are four installation troubleshooting tips:

  o  If you see either of the following error messages:

     -  net.socketException: errno = 10047
     -  Unsupported version of Windows Socket API

     Check which TCP/IP drivers you have installed. The Applet Viewer
     supports only the Microsoft TCP/IP drivers included with
     Windows 95. If you are using third-party drivers (such as Trumpet 
     Winsock) and you want to load applets over the network, you will 
     need to change over to the native Microsoft TCP/IP drivers. 

  o  If the AppletViewer does not load applets, try typing either of the 
     following at the command line:

      -  set HOMEDRIVE=c:
         set HOMEPATH=\
      -  set HOME=c:\
         
      Then restart the Applet Viewer in the same DOS session. If neither 
      of these work, try the following at the command line:

         java -verbose sun.applet.AppletViewer

     This command lists the classes that are being loaded. From this 
     output, you can determine which class the Applet Viewer is trying 
     to load and where it is trying to load it from. Check to make sure
     that the class exists and is not corrupted in some way.

  o  Fatal Error Message:

     If you receive one of the following fatal error messages while running 
     java, javac, or appetviewer: 

       -  Exception in thread NULL
       -  Unable to initialize threads: cannot find class
          java/lang/Thread" 

     Check your CLASSPATH environment variable. It might list c:\java or the 
     classes directory from an older release. You can either unset the CLASSPATH 
     variable, or set it to include only the latest version of the Java platform 
     class library.  For example: 

        C:\> set CLASSPATH=.;C:\jdk1.1.7\lib\classes.zip

     This will make sure that you are using the correct classes
     for this release.

  o  Cannot close Applet Viewer copyright window (Windows 95 only):

     In Microsoft Windows 95, the launch bar may partially cover
     the Applet Viewer copyright notice window Accept and Reject
     buttons. If this happens, you can move the Windows 95
     launch bar to the side of the desktop to allow access to
     the copyright window Accept and Reject buttons.

7.0  WORKAROUND INFORMATION
______________________________________________________________________

The following sections provide information that may be useful as 
workarounds.

  o  Windows Conventions and java.io.File

    In the Windows version of Java 1.1.5, the java.io.File made an 
    assumption about the meaning of a bare drive name such as "C:". 
    A bare drive name was assumed to refer to the root directory 
    for that drive. Thus, "C:" was equivalent to "C:\".

    The Developer Kit, java.io.File follows proper Windows conventions. 
    Windows recognizes a distinct working directory for each drive. A bare 
    drive name refers to the working directory for that drive. If your 
    software relies on "C:" being equivalent to "C:\", you will need to 
    modify your application for the Developer Kit.

  o  Win32 Peer Controls
   
     Some text controls, such as java.awt.TextArea, do not always handle
     large text strings correctly on Win32 systems. If, for example, you
     pass a 64K string to setText(), the control may display nothing. 
     
     This is not a limitation in Sun's Java 2 JDK software class libraries; 
     it is a limitation of Windows. The actual limitation is in the "peer" 
     control, the native platform control that actually appears on the 
     screen. Win32 screen controls can handle only a limited amount of 
     text. In theory, the limit is 32K. In practice, the limit may be as 
     little as 20K or as much as 60K.

7.1  Data Transfer Problems in Windows
______________________________________________________________________

A limitation in the data transfer API prevents most objects from
being copied to the Win32 clipboard. A common workaround is to convert
objects to a String representation, since String objects are not
affected by this limitation.

One popular technique for converting an object to a string is to write
the object into a ByteArrayOutputStream and convert the stream to a
String with toString(). String.getBytes() reverses the process.

There is a potential problem with this kind of byte/character
conversion. Both toString() and getBytes() rely on a locale-specific
character encoder to translate byte values to and from Unicode
character values. Not all encoders assume a one-to-one relationship
between byte values and character values. To ensure a reliable
translation, do not rely on the default locale encoder. Explicitly
specify an encoder that uses a reversible translation, such as
ISO8859_1. Do this by passing the encoder name to toString() and
getBytes():

  aString = aStream.toString("ISO8859_1");
  aByteArray = aString.getBytes("ISO8859_1");

In previous releases, ISO8859_1 was the default encoder for western 
locales on both Solaris and Win32. A program's dependence on
ISO8859_1 might not be apparent if the program was not tested under 
a non-western locale. 

Developer Kit software running on Win32 machines uses Cp1252 
(Windows Latin-1) as the default encoding for western locales. Cp1252 
does not implement a reversible byte/character translation. 

8.0  TRADEMARKS
______________________________________________________________________

IBM is a trademark of International Business Machines Corporation in 
the U.S., or other countries, or both.

The JRE is a product of Sun Microsystems, Inc. JavaSoft is an 
operating company of Sun, and develops the JRE.

Java and HotJava are trademarks of Sun Microsystems, Inc. in the U.S.
and other countries.  The Java technology is owned and exclusively
licensed by Sun Microsystems, Inc.

Other company, product, and service names may be trademarks or
service marks of others.

  THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF
  ANY KIND. IBM DISCLAIMS ALL WARRANTIES, WHETHER
  EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, THE
  IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE
  AND MERCHANTABILITY WITH RESPECT TO THE INFORMATION IN
  THIS DOCUMENT. BY FURNISHING THIS DOCUMENT, IBM GRANTS
  NO LICENSES TO ANY PATENTS OR COPYRIGHTS.
______________________________________________________________________

Copyright (c) IBM Corporation 1999, All rights reserved.

Copyright (c) 1997, 1999 Sun Microsystems, Inc.
901 San Antonio Rd., Palo Alto, CA 94303 USA.
All rights reserved.