[Peter Johnson]

Originally Posted by JesseK

I'm going to work on a direct Java implementation for NetworkTables. There is absolutely no need for JNI to be involved, and a direct Java implementation would resolve some of the shared resource issues that it looks like ntcore specifically designs for. The better reason though, is that I want runtime control over the data rate for certain sensors so we can collect better telemetry from a match.

I would be careful in rolling your own implementation. Generally speaking, network stuff is easy to get wrong and may either not work or use large amounts of wifi airtime in the various network environments used in FIRST (and our friend Murphy says this will happen at the worst possible time). Part of the goal of ntcore was to get as many languages as possible using the same tested and proven network code. I'm not sure what "shared resource issues" you're talking about with ntcore, but bug reports are happily accepted.

The runtime control of update frequency for certain sensors is something I'll be working on adding to ntcore this summer; do you really want different sensors individually updating at different rates, or would a "fast/slow" (e.g. only 2 levels) be sufficient? Would a "pull" (vs the current "push") methodology for updating values be preferred? This is possible to implement on top of ntcore, as there's flush functionality available to synchronize updates to a timed loop. Currently the flush is rate-limited to 10 Hz, but we will also be looking at changing the rate limits based on team feedback from this season, and perhaps provide a UDP option for higher-rate updates (with the tradeoff of accepting the possibility some of these updates will be dropped).

NTcore is an open source project; feel free to file a bug report on GitHub for any of these concerns and we can have a more detailed discussion in that environment.