Hey guys, I’ve been working on a handy little software testing tool that lets you test code (at least to a certain extent) without having to download to the robot. My method for this involves creating a sort of dummy version for WPILibJ with an added Swing application that lets you modify different inputs, such as joystick axis positions and sensor values, and observe the output values, primarily motor speeds and servo positions. It will hopefully help tremendously with initial code testing, although tweaking in order to get it to work correctly with the hardware will still be necessary.
So onto my (sorta) problem. I’ve been trying to really understand some of the connections between the different parts of WPILibJ, and most are pretty logical. However, there is one part which has so far escaped my grasp: the parsing package. All it contains is a group of 6 blank interfaces, which are implemented by a number of classes within the library. So my question is: what are they for? Are they used by the VM for some purpose, or are they just a simple way to classify different parts of the library? I ask because if there’s something special done by the VM, I want to make sure I account for it in my dummy library.
I’ve never programmed in Java before, but I think it may be so that each one of the inherited has the same interface (so you don’t have to call CANJaguar.Set() and Jagur.Write()) and so that another class, like a PID class, can have one interface. For example, I believe that anything that could be an input for PID is in the PIDSource class, so the PID controller can just call on the common interface.
That’s what interfaces are for, but the interfaces in this case have no methods at all, and don’t seem to be used for anything, which is confusing me. There are interfaces (PIDSource, PIDOutput, SpeedController, etc.) which are all used like a normal interface. Only the interfaces in the parsing package don’t seem to have a use.
jhersh is correct - usually, something like that would be done in Java via annotations, however the current Java being used for FRC does not support them. An interface was the least overhead solution we came up with during development. If you are just creating a dummy set of stuff, you can safely ignore the interfaces unless you plan to use the advanced plug-ins that were out for Java. Given that they have no methods, you could also just use these interfaces directly - even if methods are implemented later, you could add “dummy” implementations/calls for those methods later on.