One important thing to consider for the client side API entry point new API... please drop the thrown InterruptedException on the AutoCloseable close method for the replacement client ZooKeeper class. The current one leads to unnecessary nonsense like https://s.apache.org/fhvby
On Wed, Aug 27, 2025 at 12:25 AM Kezhu Wang <kez...@apache.org> wrote: > > Hi all, > > I have updated pr-2307[1] to the latest changes for review. > > > don't know what a bridge would look like > > > > I don't see much value in a bridge. > > I expect to use a introduced `ZooKeeper` interface as client side API > entrypoint to bring new api classes and deprecate old classes. Old > classes will be routed to new classes internally. This way we can drop > them and migrate zookeeper to the java module step by step. > > [1]: https://github.com/apache/zookeeper/pull/2307 > > Best, > Kezhu Wang > > On Wed, Aug 27, 2025 at 5:17 AM Christopher <ctubb...@apache.org> wrote: > > > > I wasn't even thinking about OSGi. I didn't even know ZK built OSGi > > bundles until you mentioned it. I'm not too familiar with that, and > > don't know what a bridge would look like. However, I probably wouldn't > > bother with a bridge. Deprecating in a minor release, allows users to > > migrate to the new, relocated API, before the deprecated API is > > removed in a future major release. I don't see much value in a bridge. > > > > On Tue, Aug 26, 2025 at 1:53 AM Kezhu Wang <kez...@gmail.com> wrote: > > > > > > Hi, > > > > > > > it would be good to consider deprecating old classes, and creating new > > > > forked (copied) ones with new package names that match the jar/maven > > > > module (org.apache.zookeeper.client.*, org.apache.zookeeper.server.*, > > > > etc.). That kind of thing would definitely be a big change, though... > > > > perhaps too disruptive. > > > > > > This could be the next major step to discuss along with the java > > > module support. `osgi` bundle is maintained in the above pr[1] or > > > branch[2] by bundling all classes from `o.a.zookeeper` except most > > > jute classes into one bundle. I have opened ZOOKEEPER-4968[3] to > > > propose a client side interface. It could be a good place to bridge > > > new classes and old classes. > > > > > > For now, the only breaking change is ZOOKEEPER-4966[4][5]. > > > > > > > Some issues we still have, though, is that we tend to have a bloated > > > > "common" jar that contains things we need everywhere, even just > > > > internal utilities. > > > > > > This could be a good caution for us too. Currently, some classes in > > > package `o.a.zookeeper.server`, say, `ExitCode` and `ZooKeeperThread` > > > and others, are splitted into `zookeeper-common`. I think we could > > > migrate them into a more suitable package or module later. > > > > > > [1]: https://github.com/apache/zookeeper/pull/2307 > > > [2]: > > > https://github.com/kezhuw/zookeeper/commits/ZOOKEEPER-233-split-server-jar/ > > > [3]: https://issues.apache.org/jira/browse/ZOOKEEPER-4968 > > > [4]: https://issues.apache.org/jira/browse/ZOOKEEPER-4966 > > > [5]: https://github.com/apache/zookeeper/pull/2306 > > > > > > > > > > > > > > > > > > Best, > > > Kezhu Wang > > > > > > > > > > > > > > > > > > On Mon, Aug 25, 2025 at 7:03 AM Christopher <ctubb...@apache.org> wrote: > > > > > > > > Yeah, you will definitely need to have distinct java package names for > > > > java modules and even basic jar sealing. Rather than merely moving > > > > files to a new jar/maven module, it would be good to consider > > > > deprecating old classes, and creating new forked (copied) ones with > > > > new package names that match the jar/maven module > > > > (org.apache.zookeeper.client.*, org.apache.zookeeper.server.*, etc.). > > > > That kind of thing would definitely be a big change, though... perhaps > > > > too disruptive. But, if you want the full value of having separate > > > > modules, that's what is probably needed. Accumulo did this a long time > > > > ago. It was a pain, but worth it in the end. Some issues we still > > > > have, though, is that we tend to have a bloated "common" jar that > > > > contains things we need everywhere, even just internal utilities. > > > > > > > > On Sun, Aug 24, 2025 at 1:29 PM Kezhu Wang <kez...@apache.org> wrote: > > > > > > > > > > Hi, > > > > > > > > > > Forget to mention, most changes are file renames between maven modules > > > > > not java packages. That is moving `ZooKeeper` from module > > > > > `zookeeper-server` to `zookeeper-client` but not from package > > > > > `o.a.zookeeper` to `o.a.zookeeper.client`. So the result is not > > > > > compatible with the java module system as far as I know. > > > > > > > > > > Best, > > > > > Kezhu Wang > > > > > > > > > > On Mon, Aug 25, 2025 at 1:18 AM Kezhu Wang <kez...@apache.org> wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I have put effort into separating `zookeeper-client` and more from > > > > > > `zookeeper` to ship ZOOKEEPER-233[1]. > > > > > > > > > > > > I start this discussion to share my progress and want to reach a > > > > > > community wide consensus on some directions. > > > > > > > > > > > > In the process of this, I found that > > > > > > `QuorumPeerConfig.ConfigException` was thrown from `ZKConfig` and > > > > > > reported it as ZOOKEEPER-4966[2]. It is impossible to split client > > > > > > classes out of server code without breaking things as > > > > > > `QuorumPeerConfig` is tied to `QuorumPeer` which is tied to massive > > > > > > other server codes. > > > > > > > > > > > > I propose to introduce superclass > > > > > > `o.a.zookeeper.common.ConfigException` for > > > > > > `QuorumPeerConfig.ConfigException`, and opened pr-2309[3] and > > > > > > pr-2306[4] for current and next releases. pr-2309[3] introduces new > > > > > > methods to throw `o.a.zookeeper.common.ConfigException` and > > > > > > deprecates > > > > > > old ones. pr-2306[4] changes old methods to throw the new exception > > > > > > class also, so it is a breaking change in source code level , it > > > > > > does > > > > > > keep abi compatibility. > > > > > > > > > > > > Based on the above, I drafted pr-2307[5] to split `zookeeper-client` > > > > > > from `zookeeper`, and `zookeeper-common`, `zookeeper-server`, > > > > > > `zookeeper-cli` further more in my fork[6]. > > > > > > > > > > > > The current situation is that: > > > > > > 1. The old `zookeeper` could be splitted to `zookeeper-common`, > > > > > > `zookeeper-client`, `zookeeper-server`, `zookeeper-cli` and also > > > > > > `zookeeper`. > > > > > > 2. `zookeeper` is a bundle package for both deployment and osgi > > > > > > just as before. > > > > > > 3. `zookeeper-server` depends only on `zookeeper-client` for tests. > > > > > > 4. `zookeeper-cli` depends on `zookeeper-server` for > > > > > > `QuorumPeerConfig` in `ReconfigCommand`. > > > > > > 5. `zookeeper-server` still contains command line tools such as > > > > > > `TxnLogToolkit`, `LogChopper`, `SnapshotComparer`, > > > > > > `SnapshotFormatter` > > > > > > and more. > > > > > > 6. Most tests still reside in `zookeeper-server` since they are > > > > > > relying on server connection, some may not but depend on > > > > > > `ClientBase`. > > > > > > 7. Given above, most client sides have to reside in > > > > > > `zookeeper-server` > > > > > > for now as maven forbid cycle dependency for tests. > > > > > > 8. `test-jar` is broken. Dependants should migrate themselves from > > > > > > `zookeeper` to `zookeeper-server`. > > > > > > > > > > > > Given all above, I want to know is it ok to ship with this many > > > > > > jars ? > > > > > > or the community wants few ? > > > > > > > > > > > > Also, there are discussions[7][8] to bump the jdk version in the > > > > > > next > > > > > > feature release, I think this would help to keep `zookeeper-client` > > > > > > to > > > > > > a lower jdk version compared to server side deployment just as what > > > > > > kafka[9] and pulsar do. > > > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-233 > > > > > > [2]: https://issues.apache.org/jira/browse/ZOOKEEPER-4966 > > > > > > [3]: https://github.com/apache/zookeeper/pull/2309 > > > > > > [4]: https://github.com/apache/zookeeper/pull/2306 > > > > > > [5]: https://github.com/apache/zookeeper/pull/2307 > > > > > > [6]: > > > > > > https://github.com/kezhuw/zookeeper/commits/ZOOKEEPER-233-split-server-jar/ > > > > > > [7]: > > > > > > https://lists.apache.org/thread/5oqm5r8jyj8w3j06ckbnbcgdt8hp3hrn > > > > > > [8]: > > > > > > https://lists.apache.org/thread/42537mr70g3n8srzxg406xlssbcsqr7w > > > > > > [9]: https://kafka.apache.org/40/documentation/compatibility.html > > > > > > [10]: > > > > > > https://github.com/apache/pulsar?tab=readme-ov-file#pulsar-runtime-java-version-recommendation
