1.3 Overview of Oracle JVM

The Oracle JVM is a standard, Java-compatible environment that runs any pure Java application. It is compatible with the standard JLS and the JVM specifications. It supports the standard Java binary format and the standard Java APIs. In addition, Oracle Database adheres to standard Java language semantics, including dynamic class loading at run time.

Java in Oracle Database introduces the following terms:

  • Session

    A session in Oracle Database Java environment is identical to the standard Oracle Database usage. A session is typically, although not necessarily, bounded by the time a single user connects to the server. As a user who calls a Java code, you must establish a session in the server.

  • Call

    When a user causes a Java code to run within a session, it is termed as a call. A call can be started in the following different ways:

    • A SQL client program runs a Java stored procedure.

    • A trigger runs a Java stored procedure.

    • A PL/SQL program calls a Java code.

    In all the cases defined, a call begins, some combination of Java, SQL, or PL/SQL code is run to completion, and the call ends.

Note:

The concept of session and call apply across all uses of Oracle Database.

Unlike other Java environments, the Oracle JVM is embedded within Oracle Database and introduces a number of new concepts. This section discusses some important differences between an Oracle JVM and typical client JVMs based on:

1.3.1 Process Area

In a standard Java environment, you run a Java application through the interpreter by issuing the following command on the command line, where classname is the name of the class that you want the JVM to interpret first:

java classname

When using the Oracle JVM, you must load the application into the database, publish the interface, and then run the application within a database session. The database session is the environment in which the Oracle JVM runs and as such is the analog of the operating system process in which a standard client JVM runs.

1.3.2 Java session initialization, duration and entrypoints

Standard client-based Java applications declare a single, top-level method, public static void main(String args[]). This method is executed once and the instantiation of the Java Virtual Machine lasts for the duration of that call. But, Oracle Java applications are not restricted to a single top-level main entrypoint, and the duration of the Oracle JVM instantiation is not determined by a single call and the exit of the call from this entrypoint. Each client begins a session, calls its server-side logic modules through top-level entry points, and eventually ends the session. The same JVM instance remains in place for the entire duration of the session, so data state such as static variable values can be used across multiple calls to multiple top-level entry points.

Class definitions that have been loaded and published in the database are generally available to all sessions in that database. The JVM instance in a given session and the Java data objects and global field values in that JVM instance are private to the session. This data is present for the duration of the session and may be used by multiple calls within the lifetime of that session. But, neither this data is visible to other sessions nor the data can be shared in any way with other sessions. This is analogous to how in a standard client Java application separate invocations of the main method share the same class definitions, but the data created and used during those invocations are separate.

1.3.2.1 Support for JDK 11 and Modules

Starting from this release, Oracle JVM supports JDK 11 and Java modules.

In JDK 11, you can associate a client-based Java application with one or more modules. The main Java class can be a member of a module, and the module can be added to the application through the Java command line argument --add-modules. These modules can, in turn, require other modules. During VM initialization, this set of modules is examined for consistency and completeness. All the modules required by the application, at any time, must be a part of the initial set of modules, which was included at VM start up.

Oracle JVM in JDK 11 functions in a similar manner. All java.se modules are automatically included in the root set of modules. The main class of an Oracle JVM session is the class of the method, whose Java stored procedure is invoked by the database call that initiates the Oracle JVM session. If this class is a member of a module, then it is added to the module root set. Other modules can be added using one of the following ways:

  • By specifying the loadjava --add-modules option, when the main class is loaded already
  • By specifying the oracle.aurora.addmods system property

The oracle.aurora.addmods system property has the same affect as specifying the client-based java --add-modules command-line argument. Alternatively, if the main class was loaded with the loadjava -add-modules command-line argument, then you do not need to specify the user of the oracle.aurora.addmods property.

In client-side Java, any modules, explicitly required by the above modules, are also included. As mentioned earlier, the final set of modules is examined for consistency and completeness at Oracle JVM session start up. In client-side Java, all modules required at any time by the Oracle Java session, including any modules called during any subsequent database calls in that session, must be members of the initial set of modules, which was included at Oracle JVM session start up.

1.3.3 The GUI

A server cannot provide GUIs, but it can provide the logic that drives them. The Oracle JVM supports only the headless mode of the Java Abstract Window Toolkit (AWT). All Java AWT classes are available within the server environment and your programs can use the Java AWT functionality, as long as they do not attempt to materialize a GUI on the server.

1.3.4 The IDE

The Oracle JVM is oriented to Java application deployment, and not development. You can write and test applications on any preferred integrated development environment (IDE), such as Oracle JDeveloper, and then deploy them within the database for the clients to access and run them.

See Also:

"Development Tools"

The binary compatibility of Java enables you to work on any IDE and then upload the Java class files to the server. You need not move your Java source files to the database. Instead, you can use powerful client-side IDEs to maintain Java applications that are deployed on the server.

Related Topics