Release Notes
Release Notes provide information about supported platforms, configuration requirements, obtaining support, and software considerations.
You can use PSE or PSE Pro Release 1.1 with the Sun Java Development Kit (JDK) 1.1. or 1.1.1. You cannot run PSE/PSE Pro Release 1.1 with JDK 1.0.2.
You can use PSE or PSE Pro on the following operating systems:
Bug Fixes in Release 1.1
The postprocessor (osjcfp) uses the java.util.zip package.
The PSE/PSE Pro source code does not use any deprecated APIs.
The java.lang.Number class is now fully supported.
The System.identityHashCode() method is now used internally instead of Object.hashCode(). This improves performance in some cases.
Code to work around a bug in java.util.BitSet has been removed.
There are several modifications and new features in this release.
PSE and PSE Pro Release 1.1 is Sun JDK 1.1 reliant. You cannot run PSE/PSE Pro 1.1 with a Java VM based on JDK 1.0.2.
There are two new constants you can specify when you invoke the Database.open() method.
If you specify one of these modes when you try to open a database, and there is a conflicting lock on the database, PSE/PSE Pro throws DatabaseLockedException instead of waiting indefinitely for the lock to be released.
Previous releases of PSE Pro included native libraries that synchronized data and performed database locking during updates. These libraries are no longer provided.
Instead, both PSE and PSE Pro allow you to specify system properties that perform these functions.
You can specify these properties in the property list passed to the ObjectStore.initialize(host, properties) method.
Since the native libraries are no longer included in PSE Pro, the following constants are deprecated and will be removed in a future release:
The ObjectStore.useFileNatives() method is also deprecated and will be removed in a future release.
You can serialize persistent objects. Also, the following PSE/PSE Pro classes implement java.io.Serializable.
New Java-Supplied Persistence-Capable Classes
PSE and PSE Pro support the new JDK 1.1 wrapper classes, java.lang.Byte and java.lang.Short, as persistence-capable classes.
It is expected that PSE and PSE Pro Release 1.1 can support inner classes. However, this feature has not been fully tested.
In PSE/PSE Pro 1.1, all constants conform to the Java standard of UPPERCASE_UPPERCASE style naming, rather than the lowercaseUPPERCASE style. In addition, all constants are in the COM.odi.ObjectStore class, rather than spread across several classes.
The UC_UC style names were available in PSE/PSE Pro 1.0.4. This allowed you to begin migrating to them before PSE/PSE Pro 1.1 was available. In PSE/PSE Pro 1.1, the JDK 1.1 compiler flags the lcUC style constants as deprecated. A future release of PSE/PSE Pro will not include these deprecated constants.
The complete list of deprecated APIs appears below.:
The following constants and methods are also included in the ObjectStore class:
Required Additions to CLASSPATH Variable
Additions to the CLASSPATH variable are needed to use PSE/PSE Pro and to run PSE/PSE Pro applications.
To use PSE/PSE Pro, you must set your CLASSPATH environment variable to contain
Make sure that entries for only one Object Design Java product are in your CLASSPATH environment variable. For example, under Windows NT, you might set CLASSPATH to something like this:
CLASSPATH=c:\mydir;C:\ODI\PSEPROJ\PRO.ZIP;C:\ODI\PSEPROJ\TOOLS.ZIP
Under UNIX, you might set it to something like this:
CLASSPATH=/home/mydir:/usr/local/psepro/pro.zip:/usr/local/psepro/tools.zip
To run the demos, you must add two other entries to the CLASSPATH variable. Instructions are in the README.htm file that is in the directory for each demo.
To develop PSE/PSE Pro applications, you should add entries to the CLASSPATH variable that allow PSE/PSE Pro to find your
The order of these entries is important. You want PSE/PSE Pro to find the annotated class files before it finds the source files. This ensures that when you run the program, the PSE/PSE Pro finds the annotated class definitions rather than the unannotated definitions. Detailed instructions for doing this are in the Class File Postprocessor documentation.
Set your PATH environment variable to contain the bin directory that is in this distribution. For example, if you are using PSE Pro on UNIX, this might be:
PATH=/home/mydir:/usr/local/jdk11/bin:/usr/local/psepro/bin
If you are using PSE on UNIX, this might be:
PATH=/home/mydir:/usr/local/jdk11/bin:/usr/local/pse/bin
If you are using PSE Pro on Windows, it might be:
PATH=c:\winnt35\system32;c:\winnt35;c:\jdk11\bin;C:\ODI\PSEPROJ\BIN;
If you are using PSE on Windows, it might be:
PATH=c:\winnt35\system32;c:\winnt35;c:\jdk11\bin;C:\ODI\PSEJ\BIN;
Requirement When Using Postprocessor
Under normal circumstances, you must postprocess together all classes in your application that you want to be persistence-capable or persistence-aware. Failure to do so can result in problems that are difficult to diagnose when you run your application. These failures generally manifest themselves as objects that are not automatically fetched from the database when needed.
Object Design recommends that you postprocess together all class files in an application. Even if a particular class does not need to be persistence-capable, postprocess it with all other class files in the application. Postprocessor options allow you to indicate which classes must be persistence-capable and which need not be.
If you are using a third-party library or using your own code as if it were a separate library, or if it is inconvenient or impossible to postprocess together all files in an application, see Postprocessing a Batch of Files Is Important.
The JDK 1.1 imposes a memory limitation of 16 MB unless you override it. If you receive a java.lang.OutOfMemory error during postprocessing, edit osjcfp to increase the runtime memory pool. For example, enter:
java -mx32m
Compatibility between ObjectStore, PSE Pro, and PSE
You can start development of an application in PSE or PSE Pro and at a later time upgrade it to ObjectStore. This section provides information to help you plan for this transition.
The license agreement states that you cannot use a PSE application to operate on a PSE Pro database. However, the current release of the software does not enforce this rule.
You can use a PSE Pro application to operate on a PSE database. If you use PSE Pro to open a PSE database for update or to recover a PSE database, PSE Pro upgrades the database to be a PSE Pro database. After a PSE database becomes a PSE Pro database, you cannot use a PSE application to access it.
To upgrade from PSE to PSE Pro, install PSE Pro and use it to operate on your databases.
The API to ObjectStore is a superset of the API to PSE and PSE Pro. All features in PSE are also in ObjectStore. The only feature in PSE Pro that is not in ObjectStore is that PSE Pro can have many sessions, while ObjectStore currently allows only one session.
Subject to the conditions listed below, postprocessed class files can run against PSE, PSE Pro, or ObjectStore.
Database Compatibility
Databases that you create with PSE or PSE Pro cannot be accessed with ObjectStore. Databases that you create with ObjectStore cannot be accessed by PSE or PSE Pro.
A majordomo list for general discussions of PSE and PSE Pro is available at pse-java-discussion@odi.com. To subscribe to this list, send a mail message to majordomo@odi.com. Put the following line in the body of the message:
subscribe pse-java-discussion your_email_address
You can purchase support for PSE Pro on a per-event, quarterly, or yearly basis. Send electronic mail to pse-pro-java-support@odi.com. When you purchase support you have access to documentation for Frequently Asked Questions (FAQs) at http://support.odi.com/pse-java.
This sections describes issues to consider concerning restrictions and known problems.
PSE and PSE Pro for Java are designed to be used from applets as well as applications. However, there are Web browser security restrictions that prevent PSE and PSE Pro from working from applets unless you use one of the following:
If you use IE 3.0, your applet must be a trusted applet. It is expected that more browsers will allow file I/O from trusted applets in the near future. Neither IE 3.0 nor any other browser allow file I/O from an untrusted applet.
When you create a database you must specify an access mode. PSE/PSE Pro throws AccessViolationException if you specify a file access mode that does not provide permission for the owner to modify the database. Otherwise, because of a limitation in Java, PSE/PSE Pro ignores the access mode specification when you create a database.
The JDK 1.1 weak link facility works correctly with PSE 1.1.
The Class File Postprocessor might misinterpret directory path name specifications under certain conditions on some UNIX platforms. This can happen when the postprocessor uses the CLASSPATH lookup mechanism to locate class files. It ignores any CLASSPATH directory element that matches the destination directory specified with the -dest option. The postprocessor determines matches by converting relative path names to absolute path names and then performing string comparison. On UNIX platforms, if a directory path name contains symbolic links, these symbolic links are not expanded. This might cause the postprocessor to not find a match that it should find because the specified destination directory does not use the symbolic links. If this problem occurs, the postprocessor displays an error message that claims that class files were previously annotated.
To avoid this problem you should observe the following rule. When referencing the directory to which the postprocessor will write annotated class files, either in a CLASSPATH or as a -dest argument, be sure to either use the absolute path name or a path name that does not involve symbolic links.
In all versions of the JDK on all platforms, the Java interface to ObjectStore might produce segmentation violations when the Java garbage collector exceeds the available C stack space. In the worst case, the garbage collector provided with the JDK recursively calls itself for each element in a linked list. Since OSJI creates a linked list for each persistent object that is modified in a transaction, it is possible to cause the C stack to overflow by modifying as few as 1400 persistent objects in one transaction. Application data structures that involve long chains of transient objects can also cause this problem.
If your application gets a segmentation violation and you believe you have modified a large number of persistent objects, try rerunning the application with a specification of the -ss option to the Java virtual machine. This option specifies a larger C stack size. The default stack size is 128 KB. You can specify a 256 KB C stack size when you start the Java virtual machine as follows:
java -ss256k ...
In a future release, the linked list data structure for modified objects will be changed so that it does not produce this failure in the garbage collector.
The documentation for PSE/PSE Pro is formatted for HTML frames. To use HTML frames, JavaScript must be enabled.
Sometimes, it is necessary to select the Back button twice to reload both text frames.
It is possible, but not recommended, to view the documentation without frames. If you must do this, the list below provides the path for the first file in each documenation component:
doc@odi.com
Copyright © 1997 Object Design, Inc. All rights
reserved.
Updated: 05/14/97 11:01:39