Release Notes for Apache Derby 10.16.1.1

These notes describe the difference between Apache Derby release 10.16.1.1 and the preceding release 10.15.2.0.

Overview

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:

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

New Features

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

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 10.16.1.1. These issues are not addressed in the preceding 10.15.2.0 release.

Issue Id
Description
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 10.15.1.0 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

Issues

Compared with the previous release (10.15.2.0), Derby release 10.16.1.1 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.

Operation Threat Mitigation
File access
  • Privacy
  • Data corruption
  • Loading of malware
Containerize application
Network access Loading of malware Containerize application
Access to Derby internals
  • Privacy
  • Data corruption
  • Loading of malware
Run Derby from the module path
Engine and server shutdown Denial of service Use authorization to restrict logins
Creation of class loaders Loading of malware -
De-registration of JDBC driver Denial of service -
Reading and setting system properties
  • Privacy
  • Denial of service
-
JMX monitoring of engine and server Harmless -
Re-loading of security policy N/A -

Build Environment

Derby release 10.16.1.1 was built using the following environment:

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

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 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.