apache > db
Apache DB Project
Font size:      

Apache Derby Release


Use the links below to download a distribution of Apache Derby. You should always verify the integrity of distribution files downloaded from a mirror.

You are currently using [preferred]. If you encounter a problem with this mirror, then please select another. If all mirrors are failing, there are backup mirrors at the end of the list. See status of mirrors.

Other mirrors:

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- [PGP] [SHA-512]
db-derby- [PGP] [SHA-512]

db-derby- [PGP] [SHA-512]
db-derby- [PGP] [SHA-512]

db-derby- [PGP] [SHA-512]
db-derby- [PGP] [SHA-512]

db-derby- [PGP] [SHA-512]
db-derby- [PGP] [SHA-512] (Note that, due to long filenames, you will need gnu tar to unravel this tarball.)

Release Notes for Apache Derby

These notes describe the difference between Apache Derby release and the preceding release


The most up to date information about Derby releases can be found on the Derby download page.

Apache Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs. More information about Derby can be found on the Apache web site. 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)

The 10.16 release family supports the following Java and JDBC versions:

  • Java SE 17 and higher with JDBC 4.2.

New Features

This is a feature release. The following significant change has been made:

  • SecurityManager deprecated - Derby no longer supports the Java SecurityManager. This is because the Open JDK team deprecated the SecurityManager and marked it for removal. This deprecation happened under the aegis of JEP 411.

New users should consult the 10.16 documentation, especially the Getting Started With Derby guide.

Existing users who want to run Derby with a SecurityManager must NOT upgrade to version 10.16. Instead, those users must continue to use older versions of Derby. Please see the Derby download page in order to understand how Derby and Java versions correspond.

Bug Fixes

The following issues are addressed by Derby release These issues are not addressed in the preceding release.

Issue Id
DERBY-7040Add dependency stanzas to maven poms
DERBY-7137Compile 10.16 into Java 17 byte code so that it won't run on earlier platforms
DERBY-7125Dead link in BUILDING.html
DERBY-7031Errors running upgrade tests from release candidate to 10.16 trunk
DERBY-7124Errors seen while running the junit-all target
DERBY-7053Further top build.xml streamlining
DERBY-7050In build.xml of derby root there's a vestigial target (+ patch)
DERBY-7087Make it possible to build and run tests cleanly on Java 15
DERBY-7110Make it possible to build and test Derby cleanly with OpenJDK 17
DERBY-7126Make it possible to build and test Derby cleanly with OpenJDK 18
DERBY-7088Make it possible to build and test Derby using JDK 16
DERBY-7046NoClassDefFoundError on 'java -jar derbynet.jar'
DERBY-7138Remove references to the Java Security Manager
DERBY-7052Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
DERBY-7057Unreferenced failing target in main build
DERBY-7038Upgrade ant version and re-write javadoc build targets to use improved <javadoc>task
DERBY-7041null pointer exception when creating view based on other views


Compared with the previous release (, Derby release introduces the following new features and incompatibilities. These merit your special attention.

Note for DERBY-7137

Summary of Change

Derby 10.16 compiles into Java 17 byte code.

Symptoms Seen by Applications Affected by Change

Derby 10.16 will not run on Java 16 or earlier JVMs.

Rationale for Change

Derby 10.16 no longer supports the Java SecurityManager (see DERBY-7138) due to its deprecation by Java 17 (see JEP 411). Java 17 and Derby 10.16 must not be used by applications which install a SecurityManager.

Application Changes Required

Applications must not use the SecurityManager if they run with Derby 10.16 on Java 17 or later JVMs. Applications which need a SecurityManager must use earlier versions of Derby and the JVM. See the Derby download page for the correspondence between Derby and JVM versions.

Note for DERBY-7138

Summary of Change

As part of JEP 411, the Open JDK team deprecated the SecurityManager and marked it for future removal. In response, Derby release 10.16 removes support for the SecurityManager.

Symptoms Seen by Applications Affected by Change

Previous Derby releases let database administrators install a Java SecurityManager. This, in turn, let applications customize access to security-sensitive objects such as files, network sockets, system properties, and class loaders. In previous Derby releases, the Derby network server installed a SecurityManager with default permissions if the administrator forgot to provide a customized security policy.

Recently, Open JDK 17 deprecated the SecurityManager and marked it for future removal. Open JDK 17 also began writing warnings to the console when applications called SecurityManager-related methods.

Open JDK 18 goes even further. Open JDK 18 forces users to set -Djava.security.manager=allow when booting an application which installs a SecurityManager. Furthermore, the meaning of that property has changed since Open JDK 11. In Open JDK 11, java.security.manager was the name of a user-written SecurityManager class. The property is now a directive which is required for applications which want to run a SecurityManager.

Incompatibilities with Previous Release

Derby 10.16 removes support for the deprecated SecurityManager. The Derby 10.16 network server no longer installs a SecurityManager with a default policy file. Derby 10.16 will fail to run under the SecurityManager.

Applications which need to run under a SecurityManager should use an earlier version of Derby, such as 10.15. Those applications will see warnings and will need to set -Djava.security.manager=allow when running on JVMs from Open JDK 17 upward.

Rationale for Change

The Open JDK team has deprecated the SecurityManager because it is too expensive to maintain. The Open JDK team feels that files and sockets can be protected better by running applications inside operating system containers.

Application Changes Required

Derby-powered applications should not rely on the SecurityManager and should no longer expect the Derby network server to install a SecurityManager with a default policy. Instead, applications should remove their own support for the SecurityManager.

The following table suggests defenses against several threats. Some threats have no defenses now. Applications must wait until the Open JDK team builds or recommends replacement defenses for the protections deprecated by JEP 411.

File access
  • Privacy
  • Data corruption
  • Loading of malware
Containerize application
Network accessLoading of malwareContainerize application
Access to Derby internals
  • Privacy
  • Data corruption
  • Loading of malware
Run Derby from the module path
Engine and server shutdownDenial of serviceUse authorization to restrict logins
Creation of class loadersLoading of malware-
De-registration of JDBC driverDenial of service-
Reading and setting system properties
  • Privacy
  • Denial of service
JMX monitoring of engine and serverHarmless-
Re-loading of security policyN/A-

Build Environment

Derby release was built using the following environment:

  • Branch - Source code came from the 10.16 branch.
  • Machine - Mac OSX 11.2.3.
  • Ant - Apache Ant(TM) version 1.10.6 compiled on May 2 2019.
  • Compiler - All classes were compiled by the javac from OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing).

Verifying Releases

It is essential that you verify the integrity of the downloaded files using the PGP and SHA-512 signatures. SHA-512 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


% pgp -ka KEYS
% pgp db-derby-X.Y.tar.gz.asc


% gpg --import KEYS
% gpg --verify db-derby-X.Y.tar.gz.asc

To verify the SHA-512 checksums on the files, you need to use a platform-specific program. On Mac OSX, this program is called shasum, on Linux it is called sha512sum, and on Windows it is called CertUtil.

We strongly recommend that you verify your downloads with both PGP and SHA-512.