#3800)

So far these versions are managed both by renovate-bot and Hermetic
Build. Since each release of Hermetic Build keeps these template
versions up to date, it's better suited to manage these versions via
Hermetic Build.

The updates should be reflected by updating
`.github/workflows/hermetic_library_generation.yaml` referenced version
to the current released one.

🤖 I have created a release *beep* *boop*
---


<details><summary>2.59.0</summary>

##
[2.59.0](googleapis/sdk-platform-java@v2.58.0...v2.59.0)
(2025-06-02)


### Features

* add logic to set universe domain to ServiceAccountJwtAccessCredentials
([#3806](googleapis/sdk-platform-java#3806))
([32dd11e](googleapis/sdk-platform-java@32dd11e))
* use debian base image for `java-library-generation`
([#3817](googleapis/sdk-platform-java#3817))
([3e3cf6d](googleapis/sdk-platform-java@3e3cf6d))


### Bug Fixes

* manage graalvm image versions via Hermetic Build templates _only_
([#3800](googleapis/sdk-platform-java#3800))
([45747cb](googleapis/sdk-platform-java@45747cb))


### Dependencies

* update dependency com.google.oauth-client:google-oauth-client-bom to
v1.39.0
([#3813](googleapis/sdk-platform-java#3813))
([c7a978e](googleapis/sdk-platform-java@c7a978e))
* update google api dependencies
([#3791](googleapis/sdk-platform-java#3791))
([4a4f77f](googleapis/sdk-platform-java@4a4f77f))
* update google auth library dependencies to v1.36.0
([#3814](googleapis/sdk-platform-java#3814))
([f54ac49](googleapis/sdk-platform-java@f54ac49))
* update grpc dependencies to 1.71.0
([#3807](googleapis/sdk-platform-java#3807))
([ce01aef](googleapis/sdk-platform-java@ce01aef))
* Upgrade Protobuf-Java to v3.25.8
([#3810](googleapis/sdk-platform-java#3810))
([2263d1d](googleapis/sdk-platform-java@2263d1d))
</details>

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>

* Add a simple benchmark for statement parser

Also fixes the pom to run the annotation processor so that
mvn -Pbenchmark actually is able to run benchmarks.

* Optimize AbstractStatementParser.statementStartsWith

I found this was taking ~25% of the CPU of pgadapter when running
the TPCC benchmark loader, which seems to generate very large DMLs.

Previously, it would call split() over the whole string with
a limit. Now, it uses Guava's lazy splitter so that it doesn't
have to copy the remainder of the string following the second
match.

For whatever reason, it seems like the previous implementation
was doing something much more expensive than just copying the
tail. For 100kb long query text, this new implementation is
1600x faster. For short queries it's only a few times faster.

Before:
Benchmark                                Mode  Cnt        Score        Error  Units
StatementParserBenchmark.isQueryTest    thrpt    5  1461962.835 ± 340237.573  ops/s
StatementParserBenchmark.longQueryTest  thrpt    5     2873.150 ±    490.611  ops/s

After:

Benchmark                                Mode  Cnt        Score        Error  Units
StatementParserBenchmark.isQueryTest    thrpt    5  4765215.378 ± 132661.232  ops/s
StatementParserBenchmark.longQueryTest  thrpt    5  4671884.683 ± 486566.506  ops/s

* perf: further micro optimizations to parser

* fix: remove supportsExplain

The `supportsExplain()` method did not actually do anything useful and
returned the wrong result. The reason that it was not useful is that:
1. Parsers that do support the EXPLAIN keyword handle these as client-side statements.
   This means that they never go into the isQuery() method.
2. Parsers that do not support the EXPLAIN keyword cannot do anything with it anyways.

* build: register clirr difference

---------

Co-authored-by: Knut Olav Løite <koloite@gmail.com>

…is#3800)

* creates unsafe mutation which allows server side timestamp

* update doc and use constant for server side timestamp

* update doc