This patch contains a number of bug fixes affecting the Java components of WebObjects 3.5.1. This patch and EOF 2.2 Patch 2 include all bugs fixed in WebObjects 3.5.1 Java Patch 2. Apple recommends this patch for anyone developing or deploying WebObjects 3.5.1 Java applications on Windows NT or Solaris. For more detailed information on this patch, please see the sections "New Features" and "Problems Fixed" below. For important general information on avoiding problems with Java code under WebObjects 3.5.1, please read TIL article 70035.
Installing WebObjects 3.5.1 Patch 3 on Windows NT 4.0
1. Download the Windows NT version of the patch from Apple's FTP site at ftp.info.apple.com. Also download the installer script, "patcher.nt.sh".
2. Log in as a user with Administrator privileges.
3. Open a Bourne shell. The Bourne shell should be available from your Start menu, under the WebObjects program group, or under your Apple root directory at NextLibrary\\Executables\\sh.exe.
4. Change to the directory containing the patch and the patch installer, "patcher.nt.sh".
5. Type the following at the shell prompt (make sure that there are no WebObjects applications running first):
./patcher.nt.sh -install WOF351_NT_Patch3.TAR.gz
For more information on using the "patcher.nt.sh" program, type the following at the command prompt:
./patcher.nt.sh -help
6. Reboot your Windows NT system
Installing WebObjects 3.5.1 Patch 3 on Solaris
1. Download the Solaris version of this patch from Apple's FTP servers at ftp.info.apple.com. Also download the installer script, "patcher.sh".
2. Log in as root. If you're not sure how to log in as root, see your system administrator.
3. Change to the directory containing the patch and the patch installer, "patcher.sh".
4. Type the following at the shell prompt (make sure that there are no EOF applications running first):
./patcher.sh -install WOF351_Solaris_Patch3.TAR.Z
For more information on using the "patcher.sh" program, type the following at the command prompt:
./patcher.sh -help
5. Reboot your Unix system
New Features
New in WebOjects 3.5.1 Patch 3
JDK 1.1.6: WebObjects 3.5.1 shipped with version 1.1.3 of Sun's Java Development Kit. This patch upgrades the JDK to version 1.1.6. The new version contains a number of bug fixes, performance improvements, internationalization improvements, and other enhancements. See Sun's JDK 1.1.6 web pages at http://java.sun.com/products/jdk/1.1.6/ and http://java.sun.com/products/jdk/1.1/CHANGES for details on JDK 1.1.6 and the changes from previous versions.
New in WebObjects 3.5.1 Java Patch 2
Java VM arguments: You may now pass "command line" arguments to the Java Virtual Machine. This is particularly useful for increasing the memory allocation pool (the garbage collected heap), which defaults to a maximum size of 16 MB. You should increase the pool size if you receive a java.lang.OutOfMemoryError exception.
Here is some sample code showing how to pass these arguments. Be sure to add the JavaVM framework to your project. In YourApplication_main.m, do something like this:
#import <WebObjects/WebObjects.h>
#import <JavaVM/NSJavaVirtualMachine.h>
int main(int argc, const char *argv[])
{
NSNumber *minHeap = [[NSNumber alloc] initWithInt:30*1024*1024];
NSNumber *maxHeap = [[NSNumber alloc] initWithInt:60*1024*1024];
NSDictionary* myArguments = [[NSDictionary alloc]
initWithObjectsAndKeys:
minHeap, @"NSJavaMinHeapSize",
maxHeap, @"NSJavaMaxHeapSize",
nil];
[NSJavaVirtualMachine setDefaultVirtualMachineArguments:myArguments];
[minHeap release];
[maxHeap release];
[myArguments release];
return WOApplicationMain(@"Application", argc, argv);
}
For a complete list of arguments, refer to the NSJavaVirtualMachine.h header in the JavaVM framework.
Problems Fixed
Corrected in WebObjects 3.5.1 Patch 3
Some exceptions not passed across Java Bridge
Apple reference # 2300566
PROBLEM:
If an Objective C exception was raised in an Objective C method called from Java, the bridge correctly converted the NSException to a Java exception and threw it in Java. If the conversion of the NSException itself raised an exception, the subsequent behavior of the application was undefined.
RESOLUTION:
The conversion exception is now caught, both exceptions are logged, and a Java UnknownError is thrown in the Java VM with the message: "Failed to convert Objective C exception to Java exception. Refer to log output for more information."
Java access violation error when bridge cannot find a class
Apple reference # 2303014
PROBLEM:
If a Java exception occurred while WebObjects was attempting to look up a Java class, the exception might not be re-raised in Objective C. If this occurred, the JavaBridge sometimes crashed when it failed to load the wrapper class.
RESOLUTION:
The JavaBridge now raises an appropriate exception in Objective C when a wrapper class can not be found.
Java object creation race condition
Apple reference # 2310235
PROBLEM:
A race condition on Windows NT sometimes allowed the Java garbage collector to reclaim a Java object while it was still needed by Objective C code, resulting in application crashes.
RESOLUTION:
The integration between Java and Objective C during the creation of hybrid objects has been improved to decrease the likelihood of premature garbage collection.
Garbage collector frees wrapped objects prematurely
Apple reference # 2310270
PROBLEM:
When a wrapped Objective C object was created in a Java method, the Objective C proxy object was not retained. Java garbage collection could then release this object while it was still in scope.
RESOLUTION:
Objective C proxy objects are now retained until the appropriate autorelease pool is deallocated.
next.util.CalendarDate constructors calculate year values incorrectly
Apple reference # 2310340
PROBLEM:
Under WebObjects 3.5.1, next.util.CalendarDate constructors did not correctly handle the two-digit year values returned by by the Java Date class' getYear() method, causing CalendarDate objects to be constructed with incorrect year values..
RESOLUTION:
These next.util.CalendarDate constructors now calculate year values correctly.
Java Bridge fails when an Objective C constructor returns nil
Apple reference # 2310395
PROBLEM:
The Java Bridge did not correctly handle the case where the Objective C base of a hybrid object returned nil from its Objective C init method.
RESOLUTION:
In this case, a NullPointerException is now raised in Java. This fix included a change to one of the header files used by the "bridget" utility. All Java projects must be rebuilt to take advantage of this fix. Please note that your code still needs to wrap Java constructors in try/catch statements to catch instantiation exceptions; see article 70035 for more details.
NSUnicodeStrings not correctly converted by Java Bridge
Apple reference # 2310656
PROBLEM:
In WebObjects 3.5.1, NSUnicodeStrings were not correctly converted into Java strings.
RESOLUTION:
Unicode strings are now detected and correctly converted into Java strings.
AutoreleasePool.finalize() releases Objective C autorelease pool
Apple reference # 2310883
PROBLEM:
The next.util.AutoreleasePool.finalize() method contained code that released the underlying Objective C autorelease pool. Although the intention of this code was to prevent leaks, it could result in an Objective C autorelease pool being released unexpectedly by routine Java garbage collection if a reference to the Java pool was not held.
RESOLUTION:
The Objective C autorelease pool is no longer released in AutoreleasePool.finalize(). If AutoreleasePool.release() is not explicitly called, the underlying Objective C pool will leak into its containing pool. Refer to article 70035 for more information about proper use of autorelease pools in Java.
Corrected in WebObjects 3.5.1 Java Patch 2
DecimalNumber: Several of the next.util.DecimalNumber arithmetic methods raised exceptions when called. These methods now work properly.
CalendarDate: The next.util.CalendarDate constructor CalendarDate(java.util.Date date) would sometimes return an incorrect date. This has been fixed.
NoSuchMethodError exceptions: WebObjects applications written in Java would occasionally raise a java.lang.NoSuchMethodError exception, when the method did in fact exist. This was caused by a race condition on the interaction between Objective C's reference counting and Java's garbage collection. This has been fixed. These exceptions could also be raised if a subclass of next.eo.CustomObject did not implement a default constructor (that is, an -init method with no parameters). Chained initializer methods would give the same result if some of the methods in the chain did not have Java equivalents. After installing this patch, a missing default constructor will generate a more meaningful error message.
Java string retain crashes: A problem was fixed where Java strings were garbage collected before WebObjects had a chance to retain them. The missing strings caused some applications to crash under heavy use.
Multiprocessor crashes on Solaris: Because of improper use of lock files, WebObjects 3.5.1 applications would sometimes crash on multiprocessor Solaris machines. This behavior is fixed in this patch.
Incorrect cloning behavior: Previously, custom Java objects did not correctly implement the Cloneable interface. With this patch installed, subclasses of NextObject and CustomObject should be cloneable.
DirectToWeb application crashing: The previous version of this patch for Windows NT caused crashes when launching a DirectToWeb application. This has been corrected in the current patch release.
EOEditingContext can now retain all referenced objects: EOEditingContext's weak references to objects caused problems with Java's multithreaded garbage collection. If you are writing an application which accesses the Enterprise Objects Framework from Java, you may encounter two problems:
+ (void)setInstancesRetainRegisteredObjects:(BOOL)flag;
+ (BOOL)instancesRetainRegisteredObjects;
If instancesRetainRegisteredObjects is YES, newly created EOEditingContexts will retain any EOs that it is observing. The default value for this flag is YES if an application contains Java, and NO otherwise. Each EOEditingContext caches the value of this flag, so it is possible to switch from one state to the other midway through your application. Note that only newly created EOEditingContexts will be affected by the flag.
In order to collect the EOs, you must either deallocate the editing context, or call the new method:
- (void)reset;
on the editing context. Calling reset causes the editing context to forget and release all of the objects that it is watching, and makes all of those objects effectively unusable. You typically will not not have to do anything to a Java WebObjects application in order to be compatible with this new behavior. A session's defaultEditingContext will get collected when the session times out, releasing all of the EOs fetched by that session.
Disclaimer
THE SOFTWARE PATCH PROVIDED FROM APPLE IS PROVIDED "AS IS" AND WITHOUT WARRANTY, EXPRESS OR IMPLIED. APPLE SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL APPLE BE LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO ANY LOST PROFITS, LOST SAVINGS OR ANY INCIDENTAL OR CONSEQUENTIAL DAMAGES, WHETHER RESULTING FROM IMPAIRED OR LOST DATA, SOFTWARE OR COMPUTER FAILURE OR ANY OTHER CAUSE, EVEN IF APPLE IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY OTHER CLAIM BY CUSTOMER OR FOR ANY THIRD PARTY CLAIM.