ajbeamon
commented
4 years ago One thing that we should make clear so that it's understood by anyone who adopts a version-locked jar for a client that needs seamless upgrades is that they will still need to handle deploying external clients (at least until a feature exists to distribute them automatically) or have a potentially painful experience trying to coordinate the upgrade.
In the former case, having to have a mechanism for deploying external clients seems like it would negate most of the benefit for now, though in the proposed version of the multi-version client that vends its own C library, I think this problem would go away.
In the latter case, there are a few issues to keep in mind if you want to support seamless upgrades. One is that you'll need to coordinate bounces of your clients with your cluster so that they can continue communicating. Another is that there is precedent for a Java binding release having substantial changes that can no longer support older API versions, in which case this coordinated bounce would also require swapping in new client code at the same time. This second problem could be mitigated by publishing multiple versions of the Java bindings, but that has some costs of its own.
In the scenario where you don't care about seamless upgrades (which may apply in the scenario you've described with development machines), then these points would matter less.
In order to make deploying our clients easier, we would like to ship a jar file that contains fdb_c. This would help us a lot in order to make setup of our development machines easier.
For that reason I would like to put libfdb_c into the jar file (for each OS). I saw this comment in the forum about this. As an alternative I would suggest we provide two jars: one with and one without the C client (the current JAR already loads code dynamically, so I am not quite sure I follow John's argument).