Skip to content

Bump the dev-dependencies group with 10 updates#67

Merged
github-actions[bot] merged 1 commit intomainfrom
dependabot/gradle/dev-dependencies-08affa026b
Mar 23, 2026
Merged

Bump the dev-dependencies group with 10 updates#67
github-actions[bot] merged 1 commit intomainfrom
dependabot/gradle/dev-dependencies-08affa026b

Conversation

@dependabot
Copy link
Copy Markdown
Contributor

@dependabot dependabot bot commented on behalf of github Mar 23, 2026

Bumps the dev-dependencies group with 10 updates:

Package From To
gradle-wrapper 9.4.0 9.4.1
software.amazon.awssdk:bom 2.42.13 2.42.18
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.21.1 2.21.2
com.fasterxml.jackson.datatype:jackson-datatype-jdk8 2.21.1 2.21.2
org.jdbi:jdbi3-caffeine-cache 3.51.0 3.52.0
org.jdbi:jdbi3-core 3.51.0 3.52.0
org.jdbi:jdbi3-noop-cache 3.51.0 3.52.0
org.jdbi:jdbi3-postgres 3.51.0 3.52.0
org.jdbi:jdbi3-sqlobject 3.51.0 3.52.0
org.jdbi:jdbi3-testing 3.51.0 3.52.0

Updates gradle-wrapper from 9.4.0 to 9.4.1

Release notes

Sourced from gradle-wrapper's releases.

9.4.1

The Gradle team is excited to announce Gradle 9.4.1.

Here are the highlights of this release:

  • Java 26 support
  • Non-class-based JVM tests
  • Enhanced console progress bar

Read the Release Notes

We would like to thank the following community members for their contributions to this release of Gradle: akankshaa-00, Attila Kelemen, Björn Kautler, dblood, Dennis Rieks, duvvuvenkataramana, John Burns, Julian, kevinstembridge, Niels Doucet, Philip Wedemann, ploober, Richard Hernandez, Roberto Perez Alcolea, Sebastian Lövdahl, stephan2405, Stephane Landelle, Ujwal Suresh Vanjare, Victor Merkulov, Vincent Potuček, Vladimir Sitnikov.

Upgrade instructions

Switch your build to use Gradle 9.4.1 by updating your wrapper:

./gradlew wrapper --gradle-version=9.4.1 && ./gradlew wrapper

See the Gradle 9.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading.

For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.

Reporting problems

If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.

We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.

Commits

Updates software.amazon.awssdk:bom from 2.42.13 to 2.42.18

Updates com.fasterxml.jackson.dataformat:jackson-dataformat-yaml from 2.21.1 to 2.21.2

Commits
  • 5639ffe [maven-release-plugin] prepare release jackson-dataformats-text-2.21.2
  • c6aa953 Prep for 2.21.2 release
  • 3406e8a Merge branch '2.20' into 2.21
  • d52ce35 Merge branch '2.19' into 2.20
  • 9150ee8 update release notes for 2.19.5
  • d8738d6 Merge branch '2.20' into 2.21
  • 3b4a0ce Merge branch '2.19' into 2.20
  • 56270df Merge branch '2.18' into 2.19
  • a9c1032 Backport #615 fix in 2.18 (#617)
  • efb186c Post-release dep version bump
  • Additional commits viewable in compare view

Updates com.fasterxml.jackson.datatype:jackson-datatype-jdk8 from 2.21.1 to 2.21.2

Updates com.fasterxml.jackson.datatype:jackson-datatype-jdk8 from 2.21.1 to 2.21.2

Updates org.jdbi:jdbi3-caffeine-cache from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-caffeine-cache's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-caffeine-cache's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.2
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)
Commits
  • c1e4d67 [maven-release-plugin] prepare release v3.52.0
  • 37f0f28 add missing license header
  • 6a6910d update maven to current version
  • e55f9fd prepare release
  • 4700b36 Merge pull request #2950 from hgschmie/dep-updates
  • 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
  • 5be9028 Fix StringTemplate bindMethodsList name generation
  • ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
  • 9aa6e24 Dependency updates
  • 5430416 Merge pull request #2946 from hgschmie/mysql-module
  • Additional commits viewable in compare view

Updates org.jdbi:jdbi3-core from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-core's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-core's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.2
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)
Commits
  • c1e4d67 [maven-release-plugin] prepare release v3.52.0
  • 37f0f28 add missing license header
  • 6a6910d update maven to current version
  • e55f9fd prepare release
  • 4700b36 Merge pull request #2950 from hgschmie/dep-updates
  • 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
  • 5be9028 Fix StringTemplate bindMethodsList name generation
  • ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
  • 9aa6e24 Dependency updates
  • 5430416 Merge pull request #2946 from hgschmie/mysql-module
  • Additional commits viewable in compare view

Updates org.jdbi:jdbi3-noop-cache from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-noop-cache's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-noop-cache's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.2
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)
Commits
  • c1e4d67 [maven-release-plugin] prepare release v3.52.0
  • 37f0f28 add missing license header
  • 6a6910d update maven to current version
  • e55f9fd prepare release
  • 4700b36 Merge pull request #2950 from hgschmie/dep-updates
  • 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
  • 5be9028 Fix StringTemplate bindMethodsList name generation
  • ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
  • 9aa6e24 Dependency updates
  • 5430416 Merge pull request #2946 from hgschmie/mysql-module
  • Additional commits viewable in compare view

Updates org.jdbi:jdbi3-postgres from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-postgres's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-postgres's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.2
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)
Commits
  • c1e4d67 [maven-release-plugin] prepare release v3.52.0
  • 37f0f28 add missing license header
  • 6a6910d update maven to current version
  • e55f9fd prepare release
  • 4700b36 Merge pull request #2950 from hgschmie/dep-updates
  • 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
  • 5be9028 Fix StringTemplate bindMethodsList name generation
  • ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
  • 9aa6e24 Dependency updates
  • 5430416 Merge pull request #2946 from hgschmie/mysql-module
  • Additional commits viewable in compare view

Updates org.jdbi:jdbi3-sqlobject from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-sqlobject's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-sqlobject's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.2
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)
Commits
  • c1e4d67 [maven-release-plugin] prepare release v3.52.0
  • 37f0f28 add missing license header
  • 6a6910d update maven to current version
  • e55f9fd prepare release
  • 4700b36 Merge pull request #2950 from hgschmie/dep-updates
  • 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
  • 5be9028 Fix StringTemplate bindMethodsList name generation
  • ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
  • 9aa6e24 Dependency updates
  • 5430416 Merge pull request #2946 from hgschmie/mysql-module
  • Additional commits viewable in compare view

Updates org.jdbi:jdbi3-testing from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-testing's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-testing's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.2
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)
Commits
  • c1e4d67 [maven-release-plugin] prepare release v3.52.0
  • 37f0f28 add missing license header
  • 6a6910d update maven to current version
  • e55f9fd prepare release
  • 4700b36 Merge pull request #2950 from hgschmie/dep-updates
  • 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
  • 5be9028 Fix StringTemplate bindMethodsList name generation
  • ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
  • 9aa6e24 Dependency updates
  • 5430416 Merge pull request #2946 from hgschmie/mysql-module
  • Additional commits viewable in compare view

Updates org.jdbi:jdbi3-core from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-core's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
  • Update to JUnit 6.0.3
  • Retire Apache Derby integration (#2866)
  • Run test suite against Spring Framework 7 (#2919)
  • Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
  • Support INOUT parameters for stored procedure Call statements (#1606)
  • Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
  • Add @Legacy annotation to restore old timestamp mapping behavior
  • Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)
Changelog

Sourced from org.jdbi:jdbi3-core's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

  • Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
  • Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
  • Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
  • Add configuration for Jacks...

    Description has been truncated

Bumps the dev-dependencies group with 10 updates:

| Package | From | To |
| --- | --- | --- |
| [gradle-wrapper](https://github.com/gradle/gradle) | `9.4.0` | `9.4.1` |
| software.amazon.awssdk:bom | `2.42.13` | `2.42.18` |
| [com.fasterxml.jackson.dataformat:jackson-dataformat-yaml](https://github.com/FasterXML/jackson-dataformats-text) | `2.21.1` | `2.21.2` |
| com.fasterxml.jackson.datatype:jackson-datatype-jdk8 | `2.21.1` | `2.21.2` |
| [org.jdbi:jdbi3-caffeine-cache](https://github.com/jdbi/jdbi) | `3.51.0` | `3.52.0` |
| [org.jdbi:jdbi3-core](https://github.com/jdbi/jdbi) | `3.51.0` | `3.52.0` |
| [org.jdbi:jdbi3-noop-cache](https://github.com/jdbi/jdbi) | `3.51.0` | `3.52.0` |
| [org.jdbi:jdbi3-postgres](https://github.com/jdbi/jdbi) | `3.51.0` | `3.52.0` |
| [org.jdbi:jdbi3-sqlobject](https://github.com/jdbi/jdbi) | `3.51.0` | `3.52.0` |
| [org.jdbi:jdbi3-testing](https://github.com/jdbi/jdbi) | `3.51.0` | `3.52.0` |


Updates `gradle-wrapper` from 9.4.0 to 9.4.1
- [Release notes](https://github.com/gradle/gradle/releases)
- [Commits](gradle/gradle@v9.4.0...v9.4.1)

Updates `software.amazon.awssdk:bom` from 2.42.13 to 2.42.18

Updates `com.fasterxml.jackson.dataformat:jackson-dataformat-yaml` from 2.21.1 to 2.21.2
- [Commits](FasterXML/jackson-dataformats-text@jackson-dataformats-text-2.21.1...jackson-dataformats-text-2.21.2)

Updates `com.fasterxml.jackson.datatype:jackson-datatype-jdk8` from 2.21.1 to 2.21.2

Updates `com.fasterxml.jackson.datatype:jackson-datatype-jdk8` from 2.21.1 to 2.21.2

Updates `org.jdbi:jdbi3-caffeine-cache` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-core` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-noop-cache` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-postgres` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-sqlobject` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-testing` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-core` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-noop-cache` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-postgres` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-sqlobject` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

Updates `org.jdbi:jdbi3-testing` from 3.51.0 to 3.52.0
- [Release notes](https://github.com/jdbi/jdbi/releases)
- [Changelog](https://github.com/jdbi/jdbi/blob/master/RELEASE_NOTES.md)
- [Commits](jdbi/jdbi@v3.51.0...v3.52.0)

---
updated-dependencies:
- dependency-name: gradle-wrapper
  dependency-version: 9.4.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dev-dependencies
- dependency-name: software.amazon.awssdk:bom
  dependency-version: 2.42.18
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dev-dependencies
- dependency-name: com.fasterxml.jackson.dataformat:jackson-dataformat-yaml
  dependency-version: 2.21.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dev-dependencies
- dependency-name: com.fasterxml.jackson.datatype:jackson-datatype-jdk8
  dependency-version: 2.21.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dev-dependencies
- dependency-name: com.fasterxml.jackson.datatype:jackson-datatype-jdk8
  dependency-version: 2.21.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-caffeine-cache
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-core
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-noop-cache
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-postgres
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-sqlobject
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-testing
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-core
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-noop-cache
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-postgres
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-sqlobject
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
- dependency-name: org.jdbi:jdbi3-testing
  dependency-version: 3.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dev-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file java Pull requests that update java code labels Mar 23, 2026
@github-actions github-actions bot merged commit 099ead8 into main Mar 23, 2026
4 checks passed
@dependabot dependabot bot deleted the dependabot/gradle/dev-dependencies-08affa026b branch March 23, 2026 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file java Pull requests that update java code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants