On 31-8-2018 15:48, vasiliy.yashkov@... [Firebird-Java] wrote:

> I continue to implement new native OO API interfaces in jaybird, but I
> ran into the problem of choosing between old and new interface when
> connecting. I can see, wire protocol has methods to identify protocol
> version, but native protocol doesn't have. How to determine when to use
> the new version of the interface, and when the old version? I see options:
>   - parsing a string returned by the isc_get_client_version to identify
> server version;
>   - using try...catch block;
>   - or use a new interface as default.
>
> Are there any other views?

As I indicated back in March, I am considering spinning out the
native/embedded implementation to a separate library, and that would
allow a 'legacy' and OO API to coexist in some form.

To facilitate such a future move, the binding to this new OO API needs
to live in a package separate from the current native bindings
(suggestions: org.firebirdsql.nativeoo for the new OO fbclient binding
(as an equivalent of org.firebirdsql.jna.fbclient), and
org.firebirdsql.nativeoo.gdsng for Jaybird's GDS-ng API (equivalent of
org.firebirdsql.gds.ng.jna). I am open to other/better names BTW.

This new implementation should then use separate GDSFactoryPlugin
implementations, with its own protocols (eg
jdbc:firebird[sql]:nativeoo:.. or maybe jdbc:firebird[sql]:fboo:native:..).

We could then also introduce new protocol aliases for the legacy native
(eg jdbc:firebird[sql]:legacy:native:..), and add a system property that
'removes' the default native url(s) from the legacy variant and 'adds'
it for the OO variant.

Failure to use the 'right' protocol (eg using the new OO api with a
Firebird 2.5 fbclient) should then be a hard failure with a clear
exception message, not a fallback to the legacy native bindings.

This would make it easier to create separate libraries for this in the
future, and may allow the nativeoo bindings to be used in fbjava as well
(although creating such additional dependencies might not be worth the
code duplication it avoids between projects).

This still leave you with the need to identify the version of the OO API
(eg if only to be able to find out if the new Firebird 4 batch API is
supported), but I don't know this API well enough to comment on that.

Mark
--
Mark Rotteveel