I think this is a reasonable thing to add. Could you explain the use case where this is necessary?
However there are some issues with the patch that need to be addressed:
1) we require all changes in minor/fix releases to be b/w compatible and generally we try to do non-b/w compatible
changes very infrequently. When you are running a highly available/reliable service you don't want to have to tell
ppl "shutdown & upgrade all of your servers and clients when you upgrade to this version". The changes
as currently implemented change both the API and wire protocol for existing functionality, this is not
something we can accept.
However, a simple workaround would be to add a new protocol (jute) type, and additional functions/callbacks
to support getting children including the stat. Take a look at zoo_set2 in the c source, this is an example where
simliar issue has happened before (although in that case jute had the stat, we just weren't providing it to
the user as part of the api for zoo_set, so zoo_set2 was added). So *get_children2(... in the C case and
probably just overload getChildren in java to have additional Stat param tacked onto the end.
2) there need to be tests included in the patch that verify this functionality
3) no tabs in the source, spaces only for indentation
Note to reviewer: ensure that the implementation ensures that the version fields in the stat correspond to
the child list returned (ie they are the same version, this is important if ppl start using the cversion
correlated with the child list itself)