readme_javavm.txt

Debian中文参考手册,系统介绍了Debian系统

Oracle9i Release 2 (9.2.0) Java Virtual Machine README

Table of Contents

1.     Oracle's Enterprise Java Server Platform -- Oracle9i JVM
1.1    Documentation
1.2    Getting Started
1.3    Configuration
1.4    Java Compatibility
1.5    Compatibility Mode
2.     Known Problems
2.1    Memory Usage
2.2    Accessibility of Server-Resident Java Source
2.3    DESCRIBE Problems with Java
2.4    Loadjava and Dropjava
2.5    Error Reporting
2.6    java.version, oracle.jserver.version, and oracle.server.version
2.7    Java && in SQL*PLUS
2.8    RMI and Sockets
2.9    Bug #895586 -- Multibyte Character Output Truncation at 255 Bytes
2.10   Bug #1330979 -- Wrong Japanese error message returned in SQLException in Java
2.11   Bug #1001690 -- Exception thrown when attaching JDB for debugging
2.12   Java Calling SQL and Vice Versa
2.13   Java and PL/SQL
2.14   Examples
2.15   SSL Limitations
3.     Natively Compiled Java Code
3.1    Upgrade, Downgrade, Import, Export
3.2    Security
3.3    Acceptable C Compiler Versions
3.4    Known issues



1. Oracle's Enterprise Java Server Platform -- Oracle9i JVM

Oracle9i Release 2 (9.2.0) includes a fully functional Java virtual
machine (VM), as well as the Java class libraries for Sun's Java
Development Kit (JDK) 1.2.1.  When combined with Oracle's JDBC and
SQLJ, this release provides an enterprise class platform, Oracle9i
JVM, for developing and deploying server-based Java applications.

1.1  Documentation

Separate hardcopy and on-line documentation are provided for the major
Java-related components of this release.


- Oracle9i Java Developer's Guide
- Oracle9i Java Tools Reference
- Oracle9i JDBC Developer's Guide and Reference
- Oracle9i SQLJ Developer's Guide and Reference
- Oracle9i JPublisher User's Guide
- Oracle9i Java Stored Procedures Developer's Guide


Always refer to http://www.oracle.com/java for the most up-to-date
information on Oracle Java products, including documentation and known
problems.

The Oracle9i Java Developer's Guide provides an overview of all Java
products and is an excellent starting point for exploring the Java
capabilities of Oracle9i.  In addition, it contains
Oracle-specific details of Java that span the individual products:
JDBC and SQLJ.
 
Please refer to these documents and their respective README files for
detailed information on each area.  Information on JVM and NComp
information is covered in this README file.

1.2  Getting Started

We recommend that you follow the examples presented in the Oracle9i
Java Developer's Guide to begin.  The demonstrations and examples in
ORACLE_HOME/javavm/demo include a HelloWorld example for Java Stored
Procedures.  Execution of this and other examples will ensure that
your installation was complete and that Oracle9i JVM is properly
enabled in your database.


1.3  Configuration

The Java Developer's Guide provides details of installing and
configuring a Java-enabled database.  Also, refer to the discussion in
Known Problems, Section 3.1, Memory Usage.

The primary init.ora parameters that can affect Java usage and
performance are shared_pool_size and java_pool_size.  

The memory specified in shared_pool_size is consumed transiently
during use of loadjava.  The database initialization process (i.e.,
executing initjvm.sql against a clean database, as opposed to the
installed seed database) requires shared_pool_size to be set to 50MB
as it loads the Java binaries for approximately 8000 classes and
resolves them.  Shared_pool resource is also consumed as
call-specifications are defined, and as dynamically loaded Java
classes are tracked at runtime.

All other Java state during runtime execution of Java is taken from
the amount allocated using java_pool_size.  This memory includes the
shared in-memory representation of Java method and class definitions,
as well as the Java objects that are migrated to session space at
end-of-call.  In the former case, the memory cost is shared among all
users.  In the latter case, in MTS mode, you will need to adjust
java_pool_size allocations based on the actual amount of state held in
static variables for each session.

As in Sun's JDK, the Java compiler (i.e., the compiler, written in
Java, that compiles Java source code to Java binaries) is known to be
a voracious consumer of memory.  If you intend to compile significant
amounts of Java source on the Oracle9i JVM, or you will be deploying
complex EJB's (which use the Compiler on the server), you should
consider increasing java_pool_size.  The default value for
java_pool_size is 20MB.


1.4  Java Compatibility

This release has been thoroughly tested with Sun's Java Compatibility
Kit for the JDK 1.3.1.  As discussed in the Java Developer's Guide,
the only platform-specific exception to compatibility applies to
materialization of user interfaces.  It is not appropriate for Java
developers to be able to display user interface componentry within the
Oracle server.  User interfaces by definition imply the presence of a
user to interact with Oracle on the server.  Since no such user is, in
general, present while Oracle is executing, it would be inappropriate
to allow arbitrary user code to bring up a user interface which might
require a response.  Remember, this restriction does not prevent you
from writing Java code that references or uses AWT or Swing classes,
as long as you do not execute code on the server that attempts to
materialize a user interface.

Oracle is committed to Oracle9i JVM keeping pace with Java and other
Internet standards.

1.5  Compatibility Mode

To use Java in the Oracle9i JVM server, you must set

    compatibility = 8.1.0

or higher.


2.  Known Problems

The following known problems encompass the VM itself, Java Stored
Procedures, and the utilities used by most Java developers, loadjava
and dropjava.  Java interaction with SQL, particularly known problems
with support for SQL-Java type translations, are discussed in the JDBC
README.

2.1  Memory Usage

Java introduces a significant development-time vs. runtime memory
usage difference that is not reflected in the installation-time
configuration assistance that is provided.  Specifically, the
installed configuration is limited to minimum, typical, and custom
installs, but there is no means in this release of querying at install
time to determine how you anticipate using Java.

During development of Oracle9i JVM applications, you will be using tools
such as loadjava, which consume memory in different ways than a
runtime Java application.  These tools are development-time only tools
and do not enter into the world of runtime applications.  As discussed
in the Java Developer's Guide, you may choose a style of development
using a client-side IDE, or you may choose to use the Java compiler on
the Oracle9i JVM.  The Compiler, which is adapted from Sun's JDK compiler,
is very memory-intensive, and may require you to increase
java_pool_size from the installed configuration value.

The following rules of thumb apply:

    - You will need more java_pool_size if you are compiling code on
      the server than if you are compiling on the client and loading
      to the server.  EJB deployment uses the Java compiler on the
      server, and therefore requires java_pool_size to be large.

    - You will need more shared_pool_size to handle loading large
      numbers of classes to the server and resolving them.

    - Under MTS, you will need to increase java_pool_size based on
      both the number of sessions and the amount of memory held in
      Java static variables at end-of-call.

    - Your runtime memory requirements at runtime will most likely be
      different than those required for Java development.  If you are
      doing Java development, we recommend the following settings:

    shared_pool_size = 50000000
    java_pool_size = 20000000

These are the default installation values for the Oracle9i JVM
custom install.

If you are deploying a Java application, the memory requirements will
be dependent on the application itself and the number of users
executing it concurrently.

2.1.1 Insufficient Memory or Resources During initjvm.sql Execution

If initjvm.sql executed properly, the total count of Java schema
objects should be greater than 8,000, as shown by:

    connect internal
    select count (*) from user_objects where object_type='JAVA CLASS';

All classes should be marked VALID, so the number of invalid classes
should be zero, as shown by:

    select count(*) from user_objects 
       where object_type='JAVA CLASS' and status != 'VALID';

If initjvm failed you should check your init.ora file to ensure that
the shared_pool_size and java_pool_size are at least 50MB and 20MB
respectively.  These values may be set incorrectly if you chose the
minimal or typical installation, which assumes you are starting with a
Java-enabled database.

2.1.2  Insufficient Memory During Compilation

If during use of the Compiler under loadjava, or during deployejb, you
have insufficient memory, you should see an error:

    A SQL exception occurred while compiling:
    <Java class that was being compiled> : ORA-04031:
        unable to allocate <some number of> bytes of shared memory 
        ("shared pool","unknown object","joxlod: init h",
            "JOX: ioc_allocate_pal")

The cure is to shut down your database and to reset java_pool_size to
a larger value.  The mention of "shared pool" in the error message is
misleading.  Reset java_pool_size, not shared_pool_size.

2.1.3  Insufficient Memory During Java Class Loading

When shared_pool_size is too low to handle the creation of class
schema objects, the operation may fail silently, leaving invalid
classes in the database.  During subsequent runtime execution, the
system will attempt to resolve any classes that are not VALID.  If it
is unsuccessful, you may see a ClassNotFoundException or a
NoClassDefFoundException at runtime.  Note that these are valid runtime
exceptions that can occur because you failed to install a class on the
server.  They do not necessarily indicate there was any problem with
shared_pool_size during loading.  You should always verify that the
class was included in the set you are loading to the server, and you
should consider using the -force option of loadjava to force the class
you're loading to replace the server-resident one.

Use the -resolve options of loadjava to request that loadjava attempt
resolution of a class when it is loaded. Normally loadjava will print
error messages when resolution fails. If these messages indicate a
memory problem or failures such as "connection lost", you can increase
the size of shared_pool_size and java_pool_size and try again.

To double check the status of a class that you have created with
loadjava, you can connect to the database in the schema containing the
class and do:

    select * from user_objects where object_name = 
        dbms_java.shortname('<classname>') ;

Among the columns of user_objects is a status.

2.2  Accessibility of Server-Resident Java Source

In previous Oracle9i JVM releases, server-resident Java source was not
accessible by the standard means used for PL/SQL.  In release 9.2.0,
if you create Java source schema objects, you can view the source
using user_source.  Specifically:

    select distinct type from user_source;

now shows Java source.  Note, however, that Java's binary standard
allows you to compile Java code on the client and only load binary to
the server.  This is the approach recommended for Java development
with Oracle9i JVM.

2.3  DESCRIBE Problems with Java

DESCRIBE of package.procedure gives "object does not exist" when the
method has a Java rather than PL/SQL implementation.  DESCRIBE of
package lists only PL/SQL procedures and excludes the Java Stored
Procedures.

2.4  Loadjava and Dropjava

Loadjava and Dropjava are java-based utilities you run on the
client-side to load java binaries, source, or jar files to the server,
and to drop the corresponding libunits.  They are documented in the
hardcopy as well as the online documentation (e.g., the Oracle9i Java
Developer's Guide).

2.4.1 We recommend that you not load source and binaries together in a
jar file.  You cannot load source (.java) and binary (.class) files
for the same class in the same jar file.

2.4.2 An important aspect of Java is its support for a binary
standard.  The Java binary standard allows you to do client-side
development and only load the Java binaries to the server.  You may
find that use of a client-side compiler and loadjava to load the
resulting binaries provides better performance than use of loadjava
with source.

2.4.4 It would be desirable to allow dropjava to drop a package, but
no such capability exists.

2.4.5 Loading large jar files may require additional shared_pool.  The
creation of java schema objects consumes memory specified in
shared_pool_size.  If you experience a problem loading large jar
files, consider increasing the value of SHARED_POOL_SIZE as a
workaround.

If you feel that there is a problem with loadjava having not properly
loaded and resolved a class, you can examine the state of loaded
classes by connecting as the user who loaded the class (e.g.,
scott/tiger) and executing:

    select * from user_objects;

Properly loaded and resolved classes should show up with status of
VALID.  A shorthand alternative to determine if any classes are not
VALID is:

    select dbms_java.longname(object_name) from user_objects 
       where object_type = 'JAVA CLASS' and status != 'VALID';

2.5  Error Reporting

Errors are often reported in a trace file.  Please examine the trace
file as your first step in isolating problems.

2.6 java.version, oracle.jserver.version, and oracle.server.version

In release 9.2.0, we return "1.3.1" for java.version property, to