Jaybird 6.0.0-beta-1 Release Notes

Initial release for evaluation.

Jaybird 6 is an incremental change from Jaybird 5.

The major changes and new features in Jaybird 6 are:

Upgrading from Jaybird 5 should be straightforward, but please make sure to read Compatibility changes before using Jaybird 6. If you’re using Jaybird with the native or embedded connections, you will need to make some additional changes. See also Upgrading from Jaybird 5 to Jaybird 6.

Bug reports about undocumented changes in behavior are appreciated. Feedback can be sent to the Firebird-java mailing list or reported on the issue tracker https://github.com/FirebirdSQL/jaybird/issues.

Jaybird 6.0.0-beta-1 was tested against Firebird 3.0.12, Firebird 4.0.5, Firebird 5.0.1 and a recent snapshot of Firebird 6.0, but should also support other Firebird versions from 3.0 and up. Firebird 2.5 and older are not supported.

Jaybird 6 will — by default — not connect to Firebird 2.5 or older. See also Pure Java will not connect to unsupported Firebird versions by default.

This driver does not support InterBase.

Jaybird 6 supports Java 17 and higher (JDBC 4.3). Support for earlier Java versions has been dropped.

Given the limited support period for Java 9 and higher versions, we limit support to Java 17, the most recent LTS version after Java 17, and the latest Java release. Currently, that means we support Java 17, Java 21, and Java 23.

Jaybird 6 provides libraries compiled for Java 17.

Jaybird 6 is modularized. The available modules are:

See also Java support in What’s new in Jaybird 6.

Jaybird supports the following specifications:

See also Maven.

Examples:

Change the version of the dependency to 6.0.0-beta-1. If you’re using the artifact id jaybird-jdkXX, change it to jaybird.

When your Jaybird dependency defines the exclusion for javax.resource:connector-api (see example below), you can remove it as Jaybird no longer has a dependency on connector-api.

For more detailed instructions, see also the information on Maven in Getting Jaybird 6.

If you use native or embedded, you now need to explicitly add jaybird-native as a dependency:

If you use native or embedded, make sure to update your JNA dependency to version 5.15.0 and artifact id jna-jpms, or remove it altogether as the dependencies will now be pulled in through the jaybird-native artifact.

If you manage your dependencies manually, you need to do the following:

If you find a problem while upgrading, or other bugs, please report it on https://github.com/FirebirdSQL/jaybird/issues.

For known issues, consult Known issues.

The minimum supported Java version of Jaybird 6 is Java 17. Our expectation is that Java version specific artifacts are no longer needed. As a consequence, the Java version has been dropped from the version number. The full version and naming convention is documented in jdp-2023-01: Version Number and Naming Scheme

As a result of these new naming conventions, the following has changed:

Furthermore, the client name reported to Firebird is now Jaybird jaybird-6.0.0 (was: Jaybird jaybird-5.0.0.java8).

Support for Firebird 2.5 has been dropped. See also Support for Firebird 2.5 dropped.

Jaybird 6 supports Firebird 3.0, Firebird 4.0, and Firebird 5.0, and provides tentative support for Firebird 6.0.

Jaybird 6 will — by default — not connect to unsupported versions (that is, Firebird 2.5 or older). See also Pure Java will not connect to unsupported Firebird versions by default.

The pure Java protocol will by default no longer try the wire protocol versions of unsupported Firebird versions. This means that — by default — only protocol version 13 (Firebird 3.0) — 18 (Firebird 5.0) are tried. As a result, attempts to connect to Firebird 2.5 or earlier will result in error “connection rejected by remote interface” (335544421 or isc_connect_reject).

The connection property enableProtocol can enable unsupported protocols, assuming a suitable protocol implementation is available on the classpath.

This connection property can have the following values:

A different default value of enableProtocol can be set using the system property org.firebirdsql.jdbc.defaultEnableProtocol. This system property is checked each time a connection configuration is created, so it can be changed at runtime. If you use a Jaybird DataSource implementation, it uses the value at the time the DataSource is created; if you use DriverManager — this can include third-party data sources, it uses the value at the time the connection is created.

The NATIVE (JDBC URL prefix jdbc:firebird[sql]:native:) and EMBEDDED (JDBC URL prefix jdbc:firebird[sql]:embedded:) protocol implementations have been moved to a separate artifact, org.firebirdsql.jdbc:jaybird-native.

If you use native or embedded connections using Jaybird, you will need to explicitly add the appropriate Maven dependency (or jaybird-native-6.0.0-beta-1.jar and jna-jpms-5.15.0.jar) to your classpath.

See also Getting Jaybird 6.

The OOREMOTE protocol (JDBC URL prefix jdbc:firebird[sql]:oo:) has been removed in Jaybird 6.

See also jdp-2022-04: Deprecate OOREMOTE (OpenOffice/LibreOffice driver) for removal.

The recommended replacement is to use LibreOffice and the builtin “Firebird External” connection option in LibreOffice Base, instead of the “JDBC” option with Jaybird on the classpath of LibreOffice.

Jaybird now uses real Java modules.

The available modules are:

We’ve tried to be liberal with exporting packages from Jaybird, but we have decided not to export some packages because we think they shouldn’t normally be accessed by users of Jaybird. If you run into problems with packages not being exported, please report this on firebird-java or on https://github.com/FirebirdSQL/jaybird/issues. Please include an explanation why you need to access a specific package. As a workaround, you can also add exports yourself with the --add-exports commandline option of java and javac and the Add-Exports manifest entry of your application (similar options exist for opens).

When the Jaybird JAR files are on the classpath, they should behave as before. For modular applications, once added to the modulepath instead of the classpath, they will behave in a more restricted fashion.

If you use Jaybird only as a JDBC driver (through java.sql.DriverManager), having the driver on the modulepath and having requires java.sql in the module-info.java of your application should be sufficient. If your code uses classes and other types from Jaybird, you will also need to add requires org.firebirdsql.jaybird.

The ChaCha64 plugin, org.firebirdsql.jaybird.chacha64, will just need to be present on the modulepath to be loaded.

The same goes for the native protocol module, org.firebirdsql.jna, but we recommend you only add it to the modulepath if you actually need native or embedded access. You also need to replace any jna-<version>.jar with jna-jpms-5.15.0.jar (the modular variant of JNA).

If you use org.firebirdsql.jna to implement a Firebird embedded provider, you’ll need to add requires org.firebirdsql.jna and an appropriate provides org.firebirdsql.jna.embedded.spi.FirebirdEmbeddedProvider with <classname> in your module-info.java. For compatibility with use on the classpath, it is recommended to also provide the META-INF/services/org.firebirdsql.jna.embedded.spi.FirebirdEmbeddedProvider file.

For more information, see also jdp-2023-13: Modularization of Jaybird.

The Boolean connection property createDatabaseIfNotExist instructs Jaybird to attempt to create the database if it does not exist yet. This property can be used in the JDBC URL, in the Properties object passed to DriverManager, and can be set on data sources.

Although Jaybird already allowed you to create databases using org.firebirdsql.management.FBManager, this is not always accessible, for example in tools or libraries that only expose or use the JDBC API. This new property provides an alternative way to create databases.

Jaybird allows you to set or override connection properties specifically for creating the database by suffixing the property name with @create (case-sensitive). This can be used to set configuration properties that are only relevant for creating the database, or — for example — to use a different user or role for creating the database than used for normal connections.

As an example:

If the database already exists, the connection will be made with user normaluser, but if the database does not exist, the database and the connection will be created with user sysdba.

For more information, see also jdp-2024-02: Create database through JDBC URL.

The pure Java implementation will now report the actual process ID (pid) in connection property isc_dpb_process_id. The native implementation already did this.

For pure Java connections, the reported process ID can be overridden using the connection property processId or the system property org.firebirdsql.jdbc.pid. This feature is retained for backwards compatibility.

When a SecurityManager is installed, the entire call-chain needs to have the RuntimePermission("manageProcess") to obtain the process ID in pure Java connections. If this permission check fails, Jaybird will silently ignore it and not set the isc_dpb_process_id based on the actual process ID.

The logging facade from package org.firebirdsql.logging has been removed, and is replaced by the Java Platform Logging API (JEP 264).

The Java Platform Logging API by default logs to java.util.logging, but it is possible to plug in different logging platforms. For example, Log4j provides the log4j-jpl dependency which will replace the default binding to java.util.logging with one to Log4j.

With this change, Jaybird no longer provides an option to specify a custom logger implementation, so the system property org.firebirdsql.jdbc.loggerImplementation is no longer supported. If you need a custom logger, you will need to implement java.lang.System.Logger and java.lang.System.LogFinder and provide the necessary service loader definition (see the Java documentation for details).

The system properties org.firebirdsql.jdbc.forceConsoleLogger and org.firebirdsql.jdbc.disableLogging are also no longer supported. Equivalent behaviour is achieved by configuring the active logging library.

Support for the “ChaCha64” wire encryption — introduced in Firebird 4.0.1 — was added for the PURE_JAVA protocol. Given this requires a dependency on the Bouncy Castle provider (bcprov-jdk18on), the plugin is made available as a separate artifact: org.firebirdsql.jdbc:chacha64-plugin on Maven or chacha64-plugin-6.0.0-beta-1.jar in the distribution zip.

When deploying manually, please make sure to also include the bcprov-jdk18on-1.78.1.jar from the lib directory of the distribution zip on the classpath.

As part of this change, Jaybird is now capable of loading EncryptionPluginSpi instances using the service loader mechanism. The API of EncryptionPluginSpi and EncryptionPlugin and other classes and interfaces in package org.firebirdsql.gds.ng.wire.crypt should still be considered unstable and internal API, so use it at your own risk to implement your own plugins. If you want to use it for implementing your own encryption plugins, let us know on firebird-java. We can then look at stabilizing the API and considering it formally a public API.

See also jdp-2023-06: ChaCha64 Support

Firebird 3.0 added packages, which can contain stored procedures and functions. The JDBC API does not provide a standard way of accessing information about packages, or the routines defined in packages. Instead of adding additional Jaybird-specific metadata methods, we’ve added an “opt-in” feature that provides access through normal metadata methods, using the “catalog” to report packages.

This feature can be enabled by setting the connection property useCatalogAsPackage to true. When this connection property is enabled, the DatabaseMetaData of that connection will have the following changes in behaviour:

The useCatalogAsPackage connection property does not result in any other behaviour.

Keep in mind, that this is non-standard behaviour, and standard JDBC tools or libraries may not work correctly when this property is enabled. This feature may be discontinued and removed in the future if Jaybird needs to implement “real” catalogs (e.g. because Firebird started supporting catalogs).

See also jdp-2023-08: Use Catalog as Package

For pure Java connections, non-holdable forward-only result sets now perform asynchronous fetches. Asynchronous fetches are implemented for protocol implementation version 11 and higher (i.e. Firebird 2.1 or higher), but are formally only supported for protocol version 13 and higher (i.e. Firebird 3.0 or higher).

In normal usage of a result set, the first fetch will be a normal synchronous fetch. If certain conditions are met, subsequent fetches will be performed asynchronously.

The conditions for using asynchronous fetch are considered an implementation detail and may change in point releases. In Jaybird 6.0.0, the conditions to enable asynchronous fetching are:

When the asynchronous fetch is triggered is also an implementation detail and may change in point releases. In Jaybird 6.0.0, the conditions to perform an asynchronous fetch are:

Native connections do not support this type of asynchronous fetching, but fbclient itself provides a different form of internal asynchronous fetching for native connections.

In Jaybird 5 and earlier, it was not possible to execute the transaction management statements COMMIT, ROLLBACK (without RETAIN or a savepoint) and SET TRANSACTION. For COMMIT and ROLLBACK it would seem to work, but subsequent use of the connection would then break because the connection assumed it still had an active transaction.

Formally, the JDBC specification says — paraphrased — that if something can be done through the JDBC API, that those API methods should be used; you should not use equivalent statements. However, from a perspective of flexibility, and for example for executing scripts, it can be useful to be able to execute those statements.

Jaybird now optionally allows you to execute COMMIT [WORK], ROLLBACK [WORK] and SET TRANSACTION […​]. By default, Jaybird 6 explicitly rejects attempts to execute those statements, instead of the half-working/half-broken situation of previous versions.

To allow execution of COMMIT [WORK], ROLLBACK [WORK] and SET TRANSACTION […​], the connection property allowTxStmts needs to be set to true. This can be done using a JDBC connection property allowTxStmts, or setAllowTxStmts(boolean) on DataSource instances.

In the implementation, the use of COMMIT and ROLLBACK will not be executed as statements on the server, but instead call Connection.commit() and Connection.rollback(). The SET TRANSACTION statement — if allowed — is executed with execute immediate, and not through a statement handle.

Enabling this feature can also make it easier to use the table reservation feature, compared to FirebirdConnection.setTransactionParameters(TransactionParameterBuffer) or FirebirdConnection.setTransactionParameters(int, TransactionParameterBuffer), which requires access to the Jaybird API interfaces.

This feature has the following limitations:

For more information, see also jdp-2024-01: Explicit support for transaction statements.

The sizes of a number of buffers used in the wire protocol were increased from 512 bytes to 8192 bytes. This specifically concerns:

This change might not be desirable in all situations as it increases the total amount of memory per connection, or there can be reasons to further increase these buffers. To address this, we have added system properties to configure a number of buffers which were previously not configurable:

These properties need to be set before Jaybird is loaded and used (e.g. on the commandline with -‍D<propertyName>=<propertyValue).

The order of buffers for input is as follows:

The order of buffers for output is as follows:

A future version may introduce connection properties to control this per connection.

The event manager now attempts to detect if the underlying database connection is broken. Once a broken connection is detected, the event manager will attempt to close or forcibly disconnect itself and report itself as not connected.

For proper detection of some types of network problems in a timely manner, it may be necessary to configure the soTimeout of the event manager before connecting. When the createFor(Connection) method has been used, this can be configured through the soTimeout connection property, or — for pure Java connections only — the setNetworkTimeout method of the Connection object.

This detection depends on actual activity, like an event posting a new count, or a new event registration.

A connection property nativeLibraryPath was added to specify the directory where fbclient (for native connections), or fbembed or fbclient (for embedded connections) can be loaded. If a file path is used instead of a directory path, the parent directory will be used for the search path. In other words, it is not possible to use it load a differently named library.

This property is only exposed as a JDBC property. For data sources, it needs to be set with setProperty(String, String) or setNonStandardProperty(String).

The primary use case for this property is for situations where configuring the system property jna.library.path is not easy to do (e.g. in third-party applications).

For embedded connections, if there is a valid FirebirdEmbeddedProvider on the classpath, it will be used instead of the location specified by nativeLibraryPath.

Client info properties were introduced in JDBC 4.0 and implemented in Jaybird 2.2. This support has been rewritten to remove some limitations and correct some problems with the previous implementation.

The new implementation discerns two types of property names:

A property named <name>@USER_SESSION is handled identical to <name>. The “without context” name is preferred and recommended for USER_SESSION properties, and Connection.getClientInfo() will use the “without context” name as the key for USER_SESSION properties.

A property named <name>@USER_TRANSACTION is set and get as <name> in context USER_TRANSACTION. When a connection is in auto-commit mode, attempts to set or get USER_TRANSACTION properties are ignored (nothing is stored, and null is returned without accessing the database).

A property named <name>@SYSTEM is retrieved as <name> in the context SYSTEM. Properties in the SYSTEM context are read-only, so they cannot be set. For Connection.setClientInfo(String, String), attempts to set a SYSTEM property result in a SQLClientInfoException, for Connection.setClientInfo(Properties), SYSTEM properties are silently ignored.

Attempts to retrieve non-existent properties, even from SYSTEM will return null and will not result in an exception.

A connection registers properties known to that specific connection. By default, only the JDBC-specified properties ApplicationName, ClientUser and ClientHostName (see also below) are known. A successful get or set of a property will register that property as a known property for the current connection only.

The method Connection.getClientInfo() will retrieve only known properties (the default properties and those registered for the current connection). It will not attempt to query or identify other variables registered in any context.

The method Connection.setClientInfo(Properties) clears (sets to NULL) known properties in USER_SESSION and — if not in auto-commit — USER_TRANSACTION if they are not included in the Properties object.

DatabaseMetaData.getClientInfoProperties() reports the JDBC-specified properties only; it will not report the additional properties registered for the current connection.

The JDBC-specified properties are:

All JDBC-specified properties are get and set in USER_SESSION. On get of ApplicationName, if this property is not currently set in USER_SESSION, it falls back to get the value from CLIENT_PROCESS@SYSTEM. The CLIENT_PROCESS@SYSTEM value can be specified using the connection property processName or system property org.firebirdsql.jdbc.processName. The ClientUser and ClientHostname properties are considered application-specific and have no default value or fallback.

Compared to the previous implementation, the important differences are:

See also jdp-2023-11: New design client info properties

The JDBC specification does not specify support for LocalDate and LocalTime on TIMESTAMP (without time zone). However, when we introduced support for the java.time types, we implemented support for getting LocalDate and LocalTime (through getObject), but did not provide support for setting values of those types (through setObject) on TIMESTAMP.

We have now addressed this inconsistency, by also introducing support for setting these types on TIMESTAMP with the following behaviour:

In previous Jaybird versions, iterating over a forward-only result set in auto-commit mode would implicitly close the result set after the last row was fetched — i.e. when next() returned false. This behaviour complied with the JDBC 3.0 requirements, but in JDBC 4.0 this requirement was removed, but still allowed.

In Jaybird 6, this implicit close has been removed. In auto-commit mode, a result set will now remain open until explicitly closed using ResultSet.close(), when any statement is executed, when the auto-commit mode is disabled, or by the close of the Statement or Connection.

As a result set close is an auto-commit boundary, this change may delay commit of the active transaction until another action on the connection. If you relied on this implicit close for correctness of your application, you may need to add an explicit call to ResultSet.close() — e.g. using try-with-resources.

For more information, see also jdp-2024-03: Do not close result set after last row in auto-commit.

Jaybird 5 introduced support for server-side scrollable cursors on Firebird 5.0 and higher in the pure Java protocol. This can be enabled using the connection property scrollableCursor=SERVER.

For implementation reasons, updatable server-side scrollable cursors had a different behaviour than the emulated client-side scrollable cursors. These differences are:

In Jaybird 6, this new behaviour is now also used for the updatable emulated scrollable cursors. The reason is that having two different sets of behaviours can be confusing, as it makes it impossible to switch between the two without having to account for the behavioural differences (either intentionally, or because you’re connecting with the native or embedded protocol, or to an older version of Firebird).

We’re considering to make server-side scrollable cursors the default in a future Jaybird version (Jaybird 7 or later).

See also jdp-2024-05: Behaviour of Updatable Result Sets.

Jaybird 6 contains a number of changes that might break existing applications.

See also Compatibility changes for details.

See Removal of deprecated classes, packages and methods in Compatibility changes for more details.

Jaybird 6 has dropped support for Firebird 2.5 (see also jdp-2021-03: Drop Firebird 2.5 support).

By default, Jaybird 6 will only connect to Firebird 3.0 and higher. See also Unsupported protocol version disabled by default.

If the version 12 protocol (Firebird 2.5) is explicitly enabled, we expect the driver to remain functional, but chances are certain metadata — e.g. DatabaseMetaData — will break if we use features introduced in newer Firebird versions.

The wire protocol versions for Firebird 2.5 and earlier are disabled by default to disallow connection for the pure Java protocol. Attempts to connect to Firebird 2.5 or earlier will result in error “connection rejected by remote interface” (335544421 or isc_connect_reject). You can use connection property enableProtocol=* or — for example — enableProtocol=10,11,12 to re-enable these protocols, or use the native protocol to connect instead.

As these protocols are not supported, it is possible things will break, especially for metadata — e.g. DatabaseMetaData if we use features introduced in newer Firebird versions.

See also Pure Java will not connect to unsupported Firebird versions by default.

Jaybird 6 does not support Java versions before Java 17. You will need to upgrade to Java 17 or higher, or remain on Jaybird 5.

Jaybird 5 will serve as a form of “long-term support” for Java 8 and 11, with maintenance releases at least until the release of Jaybird 7.

The main jaybird artifact no longer provides native and embedded support. Add the jaybird-native artifact if you use native or embedded (JDBC URL prefix jdbc:firebird[sql]:native: or jdbc:firebird[sql]:embedded:).

See also NATIVE and EMBEDDED support moved to a separate artifact.

The OOREMOTE protocol (JDBC URL prefix jdbc:firebird[sql]:oo:) has been removed in Jaybird 6.

The recommended replacement is to use LibreOffice and the builtin “Firebird External” connection option in LibreOffice Base, instead of the “JDBC” option with Jaybird on the classpath of LibreOffice.

The connection property timestampUsesLocalTimezone has been removed. The exact semantics and usage of this property were unclear. It was previously deprecated in Jaybird 5 for removal in Jaybird 6 or later.

Other code associated with this property was also removed.

The rewritten client info properties implementation may result in the following incompatibilities:

See also Rewritten client info properties support.

With the introduction of async fetch, the org.firebirdsql.gds.ng.monitor.Operation.Type enum has two new values added:

If you’re currently using the OperationAware interface to monitor and/or cancel fetches, make sure to also process STATEMENT_ASYNC_FETCH_START and/or STATEMENT_ASYNC_FETCH_COMPLETE as appropriate.

The conversions of datetime values were overhauled to use the java.time types wherever possible.

This results in some minor differences:

Attempts to prepare or execute COMMIT or ROLLBACK (without RETAIN or a savepoint) will now fail by default. In previous versions, executing these statements would work, but leave the connection in an unusable state. The exact error will — generally — be one of the following:

In the case of the execute, executeUpdate or executeLargeUpdate methods of Statement, or the prepareStatement methods of Connection, this can be resolved by allowing the execution with connection property allowTxStmts set to true.

In the case of Statement.executeQuery(String) and PreparedStatement.executeQuery(), you will need to switch to using one of the other execute, executeUpdate or executeLargeUpdate methods.

It is not possible to use the prepareCall methods of Connection with these statements. In previous versions of Jaybird, subsequent execution wouldn’t work either — or attempt to execute stored procedures called COMMIT or ROLLBACK, but it is now rejected early in the prepareCall methods of Connection. Switch to using prepareStatement.

Additionally, using Statement.addBatch(String) and PreparedStatement.addBatch() will not work with these statements. Switch to using one of the normal execute methods.

See also Support for executing transaction management statements.

Jaybird no longer upgrades TYPE_FORWARD_ONLY holdable result sets to TYPE_SCROLL_INSENSITIVE. As a result, for these result sets, only the next() navigation method is allowed, and other navigation methods will throw an SQLException, just like a forward-only non-holdable result set.

In previous versions this upgrade occurred when creating a TYPE_FORWARD_ONLY result set, either explicitly when asking for holdability HOLD_CURSORS_OVER_COMMIT, or implicitly when defaultResultsetHoldable=true (or defaultHoldable=true or result_set_holdable=true) and no holdability was specified.

If you relied on this type upgrade to access navigation methods other than next(), you will need to explicitly ask for a TYPE_SCROLL_INSENSITIVE result set.

In previous versions of Jaybird the read-only state of a connection was not retained if the transaction parameter buffer was replaced, for example by calls to setTransactionIsolation(int).

Now this has been corrected, it is possible that your code unexpectedly throws an exception with message “attempted update during read-only transaction [SQLState:42000, ISC error code:335544361]” (error isc_read_only_trans).

You need to make sure to call setReadOnly(false) if the connection was previously marked read-only. If you’re using a connection pool, you need to ensure it properly resets the read-only state of the connection when checking in or checking out the connection. For example, both Apache DBCP and Apache Tomcat connection pools requires the defaultReadOnly property to be set (i.e. to false), otherwise it will not reset the read-only state.

If overridden transaction mappings are used, and the default isolation level has isc_tpb_read, the connection will be marked as read-only. As a result, switching isolation levels will now also result in read-only transactions, even if the mapping of the other isolation level is defined with isc_tpb_write. You will need to explicitly call setReadOnly(false), or — better yet — do not override transaction mappings with a isc_tpb_read, but always use isc_tpb_write, and control read-only state only through setReadOnly.

For more information, see ResultSet in auto-commit no longer closed after last row.

For more information, see Changes to behaviour of updatable scrollable result sets.

Below list of removals may look daunting, but if you use Jaybird only as a JDBC driver, through the JDBC API, you’re likely unaffected. Although we list them as removed without deprecation, some were marked as deprecated retroactively in Jaybird 5.0.3 or later.

This section does not include all changes to packages or classes considered internal API.

Below list of removals may look daunting, but if you use Jaybird only as a JDBC driver, through the JDBC API, you’re likely unaffected.

The following breaking changes were made to the internal API, like the GDS-ng API in org.firebirdsql.gds.ng and sub-packages. These changes are primarily interesting for implementers of custom GDS-ng implementations or forks of Jaybird, or people using these low-level APIs directly.

The following changes might cause issues, though we think this is unlikely:

With Jaybird 7 the following breaking changes will be introduced.

Since Jaybird 6, the native and embedded part of the driver has been moved to a separate artifact, jaybird-native. The Jaybird Native GDS Factory plugin uses JNA to access the client library. If you want to use the Type 2 driver, or Firebird embedded, then you need to include jaybird-native-6.0.0-beta-1 and jna-jpms-5.15.0.jar on the classpath.

When using Maven, you need to specify the dependency on jaybird-native:

The fbclient.dll, fbembed.dll, libfbclient.so, or libfbembed.so need to be on the path, or the location needs to be specified in the system property jna.library.path (as an absolute or relative path to the directory/directories containing the library file(s)).

For Windows and Linux, you can add the org.firebirdsql.jdbc:fbclient dependency on your classpath to provide the native libraries for the native and local protocol. Be aware that this dependency does not support embedded.

For more information about this library, see https://github.com/mrotteveel/jaybird-fbclient.

In the future we may provide JARs with the embedded libraries of a specific Firebird version.