Here is a second rev of the release note. This attempts to clarify the extra exposure introduced by jdk1.6.
If an embedded Derby application generates its own Derby properties on the fly, and that Derby application runs in the same 1.6 VM with other JDBC applications, then you are not guaranteed that the Derby engine will pick up the custom properties when it boots.
Derby startup behavior will be non-deterministic. Sometimes the engine will pick up the custom properties and sometimes it won't.
JDBC4 introduced driver-autoloading. This causes all JDBC drivers visible to the 1.6 VM to register themselves the first time some application requests a Connection. When the embedded Derby driver registers itself, it also boots the Derby engine and the engine picks up whatever Derby properties are currently visible. An embedded Derby application may want to configure the engine properties before asking for a Connection. That embedded Derby application will not get a chance to configure engine properties if some other JDBC application in the same 1.6 VM runs first and requests a Connection. Two related bugs describe this issue in greater detail: DERBY-1428 and
DERBY-1429. DERBY-1428 affects existing customer installations running old versions of Derby on the 1.3, 1.4, and 1.5 VMs. DERBY-1429 describes the extra exposure introduced with the 1.6 VM.
There is no general solution to the problem. If two self-configuring embedded Derby applications run in the same VM, then only one of them can win.
The following workarounds may be useful:
1) Don't configure Derby properties inside your applications. Instead, specify Derby properties either on the VM startup line or in a $DERBY_HOME/derby.properties which remains constant for the VM's lifetime.
2) Don't run on the 1.6 VM. This eliminates the problem provided that you are not running more than one embedded Derby application in the same VM.
3) If (1) and (2) are not possible, then make the self-configuring Derby application run first.