Backporting the Java Instrumentation Agent

[Pierre Vacher]

Hi all,

Thanks to issue#
<https://bugs.documentfoundation.org/show_bug.cgi?id=165774>165774
<https://bugs.documentfoundation.org/show_bug.cgi?id=165774> and its
resolution with PR#183280 <https://gerrit.libreoffice.org/c/core/+/183280>
it is now possible to use the SPI services (ie: Service provider interface
<https://docs.oracle.com/javase/tutorial/ext/basics/spi.html>) that Java
offers since version 6.

Access to Java's SPI services already allows me to access logging for
embedded JDBC drivers using the *java.lang.System.Logger* facade in the
latest version of jdbcDriverOOo
<https://prrvchr.github.io/jdbcDriverOOo/CHANGELOG#what-has-been-done-for-version-150>
.

After several attempts this also makes it possible to access the SPI
service javax.sql.rowset.spi embedded in the Java SDK (i.e.
RIOptimisticProvider and RIXMLProvider) or to deploy under SPI its own
RowSet factory service.

This should allow me to finally offer a correct management of *ResultSets*
and especially of their *bookmarks* (ie: XRowLocate
<https://www.openoffice.org/api/docs/common/ref/com/sun/star/sdbcx/XRowLocate.html>)
in jdbcDriverOOo, a difficulty that until now, I have not been able to
overcome.

But if you refuse the backporting of the Java instrumentation agent then I
will have to maintain a double management (with the SPI services and
without) in the implementation of the ResultSet and although this is
possible, it will really complicate things for me.

This is why I am asking you to request the back porting (as far as
possible) of PR#183280 <https://gerrit.libreoffice.org/c/core/+/183280> and
this contrary to the rules which state that new features are not backported.

Hoping you'll break the rules, best regards.

Pierre Vacher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20250611/86cf5084/attachment.htm>