Hi, I would like to merge/backport ZOOKEEPER-842[1][2][3] and ZOOKEEPER-4970[4][5] to 3.x branches. They introduced new methods to deprecate old methods that are known to break in this module separation.
I expect this will be shipped in 4.x due to breaking changes in ZOOKEEPER-4966[6][7]. I am ok for it to be merged after 3.10.0, this way we will have enough time to review/discuss/evaluate/test it alongside with possible other valuable changes. [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-842 [2]: https://github.com/apache/zookeeper/pull/2305 [3]: https://github.com/apache/zookeeper/pull/2310 [4]: https://issues.apache.org/jira/browse/ZOOKEEPER-4966 [5]: https://github.com/apache/zookeeper/pull/2306 [6]: https://issues.apache.org/jira/browse/ZOOKEEPER-4966 [7]: https://github.com/apache/zookeeper/pull/2306 Best, Kezhu Wang On Thu, Aug 28, 2025 at 4:01 AM Christopher <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > > 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
