NetworkTables needs to change.

[JesseK]

Originally Posted by mathmogul

The repository for the new NetworkTables code is located at https://github.com/PeterJohnson/ntcore. It's included in WPILib as a Git submodule.

Do you know if there is a min / max supported Java version with this? i.e. Java 8 only?

[calcmogul]

Originally Posted by JesseK

Do you know if there is a min / max supported Java version with this? i.e. Java 8 only?

I'm not sure. WPILib uses Java 8 exclusively so that's all we've bothered to test. Peter could give a definitive answer.

[Peter Johnson]

Originally Posted by mathmogul

I'm not sure. WPILib uses Java 8 exclusively so that's all we've bothered to test. Peter could give a definitive answer.

I'll try to respond to some of the other messages in this thread later this evening, but first, a couple of quick notes.

I know of only one definite Java 8 dependency in the new NT, and I just committed it a couple days ago: I added more advanced notification features but I didn't want to break backwards compatibility with existing Java code, so I added a "default" implementation of the new interface function to ITableListener. Having a "default" like this is unfortunately a Java 8 feature, but this should be easy to work around for previous versions if you don't care about backwards compatibility. Is there real interest out there for older Java versions?

That being said, I've not actually tested it with older Java versions, so it's possible there's another dependency, but the new Java code is a thin wrapper around a JNI interface to the C++ library, so there's only 5 or 6 Java files (and only one real "implementation" class).

Java and C++ will both use the new C++ implementation, but it's still up in the air whether LabView will use the C++ library or continue using a LabView-native implementation (with the same protocol improvements).

Please note there are a few API changes in the library that required updates to wpilib code, which means it won't work "out of the box" with last year's wpilib (the C++ version I know has API breakage; I need to double-check, but the Java API should have minimal to no breakage).

It's worth noting the new C++ implementation is interoperable with old clients and servers, with the only downside being you won't have access to the new features from the older clients/servers (of course).

[JesseK]

I don't have an interest in older Java versions - just wanted to know what to look for when profiling the JNI stuff.

[Thad House]

Originally Posted by Peter Johnson

Java and C++ will both use the new C++ implementation, but it's still up in the air whether LabView will use the C++ library or continue using a LabView-native implementation (with the same protocol improvements).

I would hope that LabVIEW chooses to go with the new library. Having only 1 version of the communication protocol makes debugging MUCH easier. It's also not that hard to port, and would probably only take a day or 2 if somebody works on it full time.

1 other great change this allows is adding new languages easily. Since all the comms code is in the native library, as long as your language can somehow interop into the C library, all you need is a very thin wrapper to gain full functionality. When I ported the old NetworkTables to C#, it was not easy, especially dealing with the endian issues. Porting the new library was much much easier, took less then a day, and you only had to write interop code and not communication code.

[Tom Line]

Originally Posted by Thad House

I would hope that LabVIEW chooses to go with the new library. Having only 1 version of the communication protocol makes debugging MUCH easier. It's also not that hard to port, and would probably only take a day or 2 if somebody works on it full time.

1 other great change this allows is adding new languages easily. Since all the comms code is in the native library, as long as your language can somehow interop into the C library, all you need is a very thin wrapper to gain full functionality. When I ported the old NetworkTables to C#, it was not easy, especially dealing with the endian issues. Porting the new library was much much easier, took less then a day, and you only had to write interop code and not communication code.

I'm going to second this. We had a real headache with network tables this year. The driver station received data just fine, but trying to send data to the robot was hit-and-miss.