[Cel Skeggs]

Originally Posted by NotInControl

If I understand this correctly, backwards compatibility only applies to programs purely calling WPILib, because you wrapped it and any code dependent on the Java standard libraries will not have backward compatibility. Is that correct?

That's correct. We provide a few things from the standard libraries that aren't on the cRIO, but not anything significant.

Originally Posted by NotInControl

What happens when the users program tries to execute code written under Java 8, but then tries to exectute on the cRIO? For example, if the user makes a call to Java.io.socket networking classes, or uses automatic unboxing Double myVar = 5.
All are valid on the roboRio, but what happens when the user tries to run this code on a 2014 cRIO, does it have a compile error, run-time error, or work somehow?

When targetting the cRIO, the code is compiled with Java 1.5, not Java 8 or Java 1.3. It then gets run through Retrotranslator, which converts it to Java 1.3 bytecode.
Using unboxing should work properly, as far as I can remember. This is a language feature, not a bytecode or library feature. (You can use all Java 1.5 language features safely on the cRIO when using the CCRE, as far as I know.)
Using java.net.Socket will cause a compile-time error when targeting the cRIO (but not when targeting the roboRIO). This isn't an issue, though, because you can just use ccre.net.Network.connect(addr, port), which wraps both Squawk and Java SE interfaces for you into one interface.

In general, things will either just work or have a compile-time error. There are few cases when something will fail at runtime.

Originally Posted by NotInControl

Thanks for putting this together,
Kevin

Of course! Since it's licensed under the LGPL, any team that wants to use it (or any subset, really, but if you're going to use part of it, you may as well use the rest) is free to do so.