There was no way to atomically check for a key in the table,
and then setting if it if non existant. Back before persistent
this was not a problem, however now it is, as its possible for
values to be added before team's robot programs start. This makes
the old method of calling Put*** methods in RobotInit invalid.
This adds SetDefault methods, which do this atomically.
Since we now get ConnectionInfo when setting a connection listener,
there is some good information in there that teams could use.
Implemented using default interface methods, so teams should see no
change if they don't implement the Ex methods.
I noticed that the connection listener methods don't exist at all in
C++, so they did not get added there.
There's a lot of buzz going around the internet about people trying to
get ntcore working on other devices. One of the things that makes it
harder is having to have a separate jar for each platform. What this
change does is if the loading of the extracted library fails, it will
attempt to load ntcore from the path. This means that a program like
GRIP can just provide the libntcore.so and not have to worry about
compiling different versions for different platforms.
These are good to have for backwards compatibility, but discouraged for new
development (default-taking functions should be used instead). The reason
is that the exceptions must be explicitly handled and may initially work but
then fail at an inopportune moment.
Mark the similar Java functions as deprecated as well for the same reason.
Update all the docs for consistency.
Mark overridden functions as such in both C++ and Java.
Make IsPersistent and GetFlags const in C++.
This enables listeners to be notified of not only value updates, but also flag
changes and deletions by using a bitmask to specify what notifications are
desired. The old API (which only provided a new/not new) flag is still
supported. This also subsumes the feature to listen to local changes (that's
one of the bitmask options).
The default behavior is to only notify remote changes, but for some
applications (e.g. GUI's) it's advantageous to know about local
changes as well.
This is (slightly) optimized in that local changes only result in
additional resources being consumed if (any) local listeners have been
created.
- Ignore no-op calls to setServerMode() / setClientMode().
- Duplicate calls to initialize() act as a restart.
- shutdown() silently does nothing if not running.
The JNI bindings are built directly into the shared library. In the gradle
build, all built shared libraries are embedded into the generated jar.
Java bindings may be disabled via -DWITHOUT_JAVA (cmake) or -PskipJava=true
(gradle).
TODO:
- getEntryInfo() and RPC are not yet implemented.
- The cmake build doesn't integrate the built objects into the jar.
- The Java client and server tests are not built (but have been manually
tested).
This has not yet been tested on Windows.
