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.
Without a GCC installation that can build both 32 and 64 bit executables, the native build will fail on 64 bit Linux machines with an error about unsigned __int128 being undefined. GCC does not support __int128 on 32 bit targets, and GCC was using it via a standard library implementation header intended for 64 bit machines.
Instances of "arm" were replaced with "ARM" where the acronym was intended.
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.
Trying to build with the android standalone compiler, and these 2 things
were causing errors. I don't know what an equivalent to basename would
be, because I don't really know what it does.
For consistency with Java NetworkTable; also makes these data types easier
to use (although they are less efficient as they require a memory allocation
and data copy).
JavaGlobal was unconditionally attaching to (okay) and detaching from (bad)
the current thread during destruction. We don't want to do this if the
destructor gets called from an attached thread. Instead, use GetEnv to
first try to get the environment, and only attach and detach if it returns
an error saying the thread is detached.
Also, make sure notifier callbacks appropriately free Java locals to avoid
running out of local variable space.
During JVM shutdown, some JNI calls may not return, so it's not possible to
reliably perform a join() during static variable destruction (which occurs
as the JVM unloads the JNI module).
Also, due to static variable destruction, it's not safe to use any members
of a static class instance from a separate thread of execution.
SafeThread is a templated thread class and a related owner class that's
designed for safe operation and shutdown of threads in the presence of
callbacks that may not return. It also passes ownership of variables from
the static instance to the thread, so the thread can safely operate until
it exits (the last operation of the thread being to destroy its instance).
Notifiers, RpcServer, and Logger now use SafeThread to ensure race-free
destruction in both C++ and Java.
All Java callback threads are now marked as Java daemon threads so they
don't keep the JVM running after main() terminates.
All Java callback threads are now named so their purpose is more easily
identified in a debugger.
Add SetRpcServerOnStart and SetRpcServerOnExit (similar to Listener).
