Apache Derby 10.4.2.0 Release
Use the links below to download a distribution of Apache Derby from one of our mirrors. You should always verify the integrity of distribution files downloaded from a mirror.
There are four different distributions:
- bin distribution - contains the documentation, javadoc, and jar files for Derby.
- lib distribution - contains only the jar files for Derby.
- lib-debug distribution - contains jar files for Derby with source line numbers.
- src distribution - contains the Derby source tree at the point which the binaries were built.
db-derby-10.4.2.0-bin.zip [PGP] [MD5]
db-derby-10.4.2.0-bin.tar.gz [PGP] [MD5]
db-derby-10.4.2.0-lib.zip [PGP] [MD5]
db-derby-10.4.2.0-lib.tar.gz [PGP] [MD5]
db-derby-10.4.2.0-lib-debug.zip [PGP] [MD5]
db-derby-10.4.2.0-lib-debug.tar.gz [PGP] [MD5]
db-derby-10.4.2.0-src.zip [PGP] [MD5]
db-derby-10.4.2.0-src.tar.gz [PGP] [MD5] (Note that, due to long filenames, you will need gnu tar to unravel this tarball.)
There are two separate Eclipse plugins for Derby:
- derby_core_plugin - provides the Derby jar files to other plugins in Eclipse.
- derby_ui_plugin - provides an Apache Derby Nature in Eclipse for easy database application development.
derby_core_plugin_10.4.2.zip [PGP] [MD5]
derby_ui_plugin_1.1.2.zip [PGP] [MD5]
Please note: both plugins must be installed for full functionality. For information on installing and using the Derby plugins for Eclipse, please see the Using the 10 Core and 1.1 UI Derby plug-ins page.
Release Notes for Derby 10.4.2.0
These notes describe the difference between Derby release 10.4.2.0 and the preceding release 10.4.1.3.
Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs.
Derby functionality includes:
- Embedded engine with JDBC drivers
- Network Server
- Network client JDBC drivers
- Command line tools: ij (SQL scripting), dblook (schema dump), and sysinfo (system info)
This is a maintenance release. No new features were added.
The following issues are addressed by Derby release 10.4.2.0. These issues are not addressed in the preceding 10.4.1.3 release.
|DERBY-3836||On 10.4 branch JMX tests fail with security exceptions when run against classes|
|DERBY-3827||Add Apache 2.0 license headers to a number of files|
|DERBY-3816||Administration Guide topics on unsupported DB2 driver should be removed|
|DERBY-3813||Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.|
|DERBY-3803||'org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest' failures on JVM 1.5 on trunk, 10.4 and 10.3|
|DERBY-3799||NullPointerException when accessing a clob through a pooled connection|
|DERBY-3791||Excessive memory usage when fetching small Clobs|
|DERBY-3786||Assert failure in CacheEntry.unkeepForRemove when running stress.multi|
|DERBY-3783||LOBStreamControl shouldn't throw SQLException|
|DERBY-3781||PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state|
|DERBY-3779||Add client side JDBC statement pool documentation|
|DERBY-3777||SecureServerTest, SSLTest are failed on Zos with exit code 143 starting network server|
|DERBY-3776||testGetBytes under BlobClob4BlobTest failed on Zos with encoding issue|
|DERBY-3775||BlobStoredProcedureTest failed on Zos: AssertionFailedError: Error SYSIBM.BLOBGETPOSITIONFROMLOCATOR returns the wrong value for the position of the Blob expected:<8> but was:<-1>|
|DERBY-3774||jdbc4/ClobTest fails on Zos with AssertionFailedError: Streams differ at index 0 expected:<200> but was:<72>|
|DERBY-3773||ImportExportLobTest failed on Zos Clobs differ at index 1 expected:<99> but was:<196>|
|DERBY-3771||testClasspathChecker under SysinfoCPCheckTest failed on Zos|
|DERBY-3768||Make EmbedBlob.length use skip instead of read|
|DERBY-3766||EmbedBlob.setPosition is highly ineffective for streams|
|DERBY-3764||Union Query fail on Derby 10.4.1.3|
|DERBY-3745||Derby can leak classloaders in an app server environment|
|DERBY-3741||SQL LENGTH function materializes CLOB into memory|
|DERBY-3736||Revoking a column level privilege from a user, a prepared statement relying on that privilege can still be executed|
|DERBY-3735||Incorrect position calculation in PositionedStoreStream with read(byte(),...)|
|DERBY-3734||Maximum value allowed for derby.storage.fileCacheSize (100) is too low for large system. Increase the maximum value and redocument the property.|
|DERBY-3732||SQL Length function materializes BLOB into memory|
|DERBY-3730||Bundle-SymbolicName: needed in Derby manifest for OSGi 4 environment|
|DERBY-3726||Don't call RAFContainer.padFile() from instances of RAFContainer4|
|DERBY-3725||add more information to the XSDB1:ERROR XSDB1: Unknown page format at page error|
|DERBY-3723||Reset current schema to default (user name) when creating a new logical connection in the client driver|
|DERBY-3718||NPE when firing a trigger|
|DERBY-3709||Exception printed by replication test: Could not perform operation because the database is not in replication master mode.|
|DERBY-3708||setting tracedirectory from the command line does not work|
|DERBY-3704||If an IOException is encountered during establishment of the connection, Network Server should print the root exception to the console instead of a generic message|
|DERBY-3701||java.lang.Exception: DRDA_UnableToAccept.S:Unable to accept connections and client hang if tracing is turned on but traceDirectory does not exist|
|DERBY-3695||NullPointerException when invoking statement event listeners if one of the listeners is null|
|DERBY-3693||Deadlocks accessing DB metadata|
|DERBY-3692||'javax.transaction.xa.XAException' ++ in 'J2EEDataSourceTest'|
|DERBY-3690||EmbedPooledConnection doesn't reset schema when creating a new logical connection|
|DERBY-3668||Remove JDBC 3.0-specific topics from Reference Manual and merge implementation notes as needed|
|DERBY-3658||LOBStateTracker should not use SYSIBM.CLOBRELEASELOCATOR when the database is soft-upgraded from 10.2|
|DERBY-3657||Comment in template security policy incorrectly says that JMX is not enabled by default|
|DERBY-3649||can't call a stored function with an aggregate argument without getting the following error: ERROR 42Y29|
|DERBY-3629||Tools Guide should document continuation marker for ij|
|DERBY-3625||XSDA3 error in concateTests in lang.LangHarnessJavaTest caused by bug in SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE()|
|DERBY-3622||SYSCS_UTIL.SYSCS_EMPTY_STATEMENT_CACHE needs a better description in the reference manual|
|DERBY-3613||SELECT DISTINCT field FROM TABLE_NAME GROUP BY field, field2|
|DERBY-3612||Developer's Guide needs correction on garbage collection|
|DERBY-3602||If derbytesting.jar is in a different directory than the derby jars SystemPrivilegesPermissionTest fails with java.security.AccessControlException|
|DERBY-3596||Creation of logical connections from a pooled connection causes resource leak on the server|
|DERBY-3595||TableFunctionTest.SpecialCollation and NoSpecialCollation fail with IBM iseries in checkGetXXXCalls|
|DERBY-3588||suites.All fails to run on Jvm 1.5 when built with JDK 1.5 (Failed to invoke suite(): .jdbc4._Suite)|
|DERBY-3581||Changing certain properties on client DataSource objects causes existing connections to reflect the new values|
|DERBY-3579||The Developer's Guide incorrectly describes the behavior of transactions inside procedures and functions|
|DERBY-3574||With client, attempting to get the lob length after commit or connection close if there was a call to length() before commit does not throw an exception|
|DERBY-3546||Failed to get database schemas of a JAR database|
|DERBY-3543||NetworkServerControl with options but no command does not give usage message|
|DERBY-3469||Clob.length() doesn't detect a closed underlying connection in a consistent way|
|DERBY-3446||Make ResultSet.getStatement return the correct statement when created by a logical statement|
|DERBY-3409||Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed|
|DERBY-3401||Removing a ConnectionEventListener from a PooledConnection during its connectionClosed() callback causes other ConnectionEventListener callbacks to be missed|
|DERBY-3397||Derby 10.3.1.4 and 10.3.2.1 break scrollable result sets? Hibernate Query.setFirstResult and/or setMaxResults|
|DERBY-3381||"ERROR XSDA3: Limitation: Record cannot be updated or inserted due to lack of space on the page...." in suites.All|
|DERBY-3360||Invalid method java.lang.Integer >> void <init>(short) because java.lang.NoSuchMethodException: java.lang.Integer.<init>(short)|
|DERBY-3338||CancelQueryTask.forgetContext() could be simplified.|
|DERBY-3313||JDBC client driver statement cache|
|DERBY-3307||NPE in PooledConnction event notification handling if a null listener is added|
|DERBY-1848||jdbcapi/SetQueryTimeoutTest.java fails on IBM wctme 5.7|
|DERBY-48||A connection request that has a default schema that is being created by another transaction will fail to connect|
Compared with the previous release (10.4.1.3), Derby release 10.4.2.0 introduces the following new features and incompatibilities. These merit your special attention.
Note for DERBY-3701: An error message will be logged to derby.log if the Network Server tracing file cannot be created. Starting with version 10.5, the Network Server will attempt to create the trace directory if it does not exist. Any intervening directories in the given path will also be created if possible.
Note for DERBY-48: In Derby, a user's initial default schema is named the same as the user name, or APP if a user is not provided at connect time. This schema is implicitly auto-created the first time a schema object is created in that schema.
Note for DERBY-3701
Summary of Change
An error message will be logged to derby.log if the Network Server tracing file cannot be created. Starting with version 10.5, the Network Server will attempt to create the trace directory if it does not exist. Any intervening directories in the given path will also be created if possible.
Symptoms Seen by Applications Affected by Change
Before the fix for DERBY-3110, if derby.drda.traceAll was set to true and the derby.drda.traceDirectory was set to a non-existent directory, no tracing would occur and no error would occur. After the fix for DERBY-3110, an error "java.lang.Exception: DRDA_UnableToAccept.S:Unable to accept connections" would occur and the client would hang and no tracing would occur. With this fix for version 10.5 and higher, the Network Server will attempt to create the trace directory if possible. For 10.4.2 (and the next release on the 10.3 branch), the Network Server will still not try to create the directory. For all these releases the Network Server will print an error on session connect if there is any problem creating the trace file, but the Network Server will not cause the session connection to fail. Users who have trace turned on and the trace directory set to a non-existent directory may now see exceptions in the derby.log on connect indicating that the trace file is not found or with 10.5 or higher they may see tracing occur where it did not before.
Incompatibilities with Previous Release
Tracing properties will not be ignored or cause the client to hang if the trace directory is set to a non-existent directory.
Rationale for Change
The tracing properties should not be summarily ignored or cause the client to hang if the trace directory does not exist.
Application Changes Required
Applications that counted on the derby.drda.traceAll property being ignored if derby.drda.traceDirectory was set to a non-existent directory, need to turn tracing off or they may now see many errors in the derby.log or large amounts of tracing.
Note for DERBY-48
Summary of Change
In Derby, a user's initial default schema is named the same as the user name, or APP if a user is not provided at connect time. This schema is implicitly auto-created the first time a schema object is created in that schema.
Previously, this auto-creation would be performed as part of the user transaction. This would sometimes lead to locking issues as described in this issue. With this change, the auto-creation is now performed and committed immediately in a separate sub-transaction.
Symptoms Seen by Applications Affected by Change
The initial default schema will be present in cases where it previously would not yet have been created: If the user transaction that creates a schema object leading to auto-creation of the initial default schema rolls back for some reason after having created the schema, up till now the auto-creation of the initial default schema would be rolled back as well. Since it is now created and committed in a sub-transaction, the schema creation will not be rolled back: the default schema will persist.
Incompatibilities with Previous Release
Most applications should not be impacted by this change, but there are some corner cases as described below:
If the application tests for the existence of the initial default schema by querying Derby system tables, the results could now be different than in earlier releases, if the test is made after a rollback as described in the previous section.
Since the initial default schema will now potentially exist in cases where it would previously not exist, schema operations may be impacted, e.g. where before a DROP SCHEMA <default schema name> RESTRICT would fail due to it not yet existing, it could now work (if empty), depending on when the drop attempt is made.
Rationale for Change
Implicit schema creation is now performed in its own transaction to avoid deadlocks with other connections accessing the same schema.
Doing this is a separate transaction avoids holding dictionary locks longer than necessary, cf. DERBY-48 and thus reduces the chance for deadlocks.
Application Changes Required
Verify that the application code does not rely on the initial default schema being absent after a rollback.
Derby release 10.4.2.0 was built using the following environment:
- Branch - Source code came from the 10.4 branch.
- Machine - Mac OS X Version 10.5.4
- Ant - Apache Ant version 1.7.0 compiled on December 13 2006.
- JDK 1.4 - Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_16-b05-302)
- Java 6 - Java(TM) SE Runtime Environment (build 1.6.0_01-dp-b06-101)
- OSGi - The Apache Felix project supplied felix.jar, which was used to build org.apache.derby.osgi.EmbeddedActivator.
- Compiler - A Java 5 compiler was used to build all classes: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
- JSR 169 - J2ME libraries were supplied by phoneme.dev.java.net (CDC, Foundation Profile, and Personal Basis Profile meeting the 1.1.2 specifications). JSR169 libraries were supplied by java.sun.com.
It is essential that you verify the integrity of the downloaded files using the PGP and MD5 signatures. MD5 verification ensures the file was not corrupted during the download process. PGP verification ensures that the file came from a certain person.
The PGP signatures can be verified using PGP or GPG. First download the Apache Derby KEYS as well as the asc signature file for the particular distribution. It is important that you get these files from the ultimate trusted source - the main ASF distribution site, rather than from a mirror. Then verify the signatures using ...
% pgpk -a KEYS % pgpv db-derby-X.Y.tar.gz.asc or % pgp -ka KEYS % pgp db-derby-X.Y.tar.gz.asc or % gpg --import KEYS % gpg --verify db-derby-X.Y.tar.gz.asc
To verify the MD5 signature on the files, you need to use a program called md5 or md5sum, which is included in many unix distributions. It is also available as part of GNU Textutils. Windows users can get binary md5 programs from here, here, or here.
We strongly recommend you verify your downloads with both PGP and MD5.