Java or C++ in 2021

If you are starting a team nearly from scratch, are there any particular benefits of selecting Java over C++ or vice versa from the technical perspective?

These things are the givens:

  • programming mentors could do either
  • there are a couple of kids who already know Java but who could easily pick up C++ (or at least the basic concepts required for WPIlib)
  • we’ve got one Romi to start training on, and will probably get more once our income is > $0
  • Java is use in the AP CS class (or at least the older one). As a community team, the schools where kids are coming from may or may not offer it and I have no way of knowing at this time.

Thanks for any insights you can offer.

1 Like

Generally, a lot more teams use Java, so the support you can get from others in the community is more readily available.
I also prefer Java because I find the error messages to be more verbose and helpful. (I’ve spend a lot more time with Java though, so it might be for that reason)

5 Likes

Even with the 2nd quoted point’s caveat, having interested students already know the basics of the language is a great head start for getting code up and running while the mentors focus on getting newer students up to speed. On these two alone id go with Java.

Edit: I realize that you wanted more technical perspectives, I dont think this really fits? Unless you count the technicals of running a team…

IIRC C++ can be “optimized better”, but outside of select teams who really go hard on programming (i.e. 971) the optimization doesnt really bring many improvements to the table for the average team.

5 Likes

I’ll add that if you’ve already committed to Java but realllllly need native code, there’s always JNI/JNA.

1 Like

Yes, but - A (relatively) big component of C++'s “high performance” argument is to get rid of the Java garbage collector (non-deterministic slowdowns, outside the control of the user). Coupled with the fact that processes can be set to realtime priority on the RIO, it does help reduce jitter in the timing of the periodic loops.

I’ve not seen anyone publish a rigorous study with different permutations of FRC hardware to know when/how it really matters. But at least in theory, it would make a difference if you rely on very consistent realtime performance.

JNI has some potential to add more-highly-optimized code into Java, but won’t be able to remove the Garbage Collector hits.

True, but as a WPILib developer who had to write a lot of JNI code for the state-space library, I can tell you that JNI is a pain, even with custom JNI utilities to make it easier.

1 Like

Determinism and low jitter is especially important for aggressive feedback control.

It would take me too long to dig up hard data, but I can offer some rules of thumb as a team who goes hard on the last 1% of controls performance. We use C++, TimedRobot’s AddPeriodic() for synchronous controller scheduling, and RT thread priorities to improve scheduling jitter (think on the order of ±0.1ms for a 5ms loop).

Here’s example code: Robot-2020/Robot.cpp at main · frc3512/Robot-2020 · GitHub

Fast-accelerating stuff like flywheels

You want 200Hz sample rate and minimal measurement latency. Latencies beyond 20ms are untenable because it oscillates too much. That means doing roboRIO controllers with CAN encoders won’t work because the status frames are nondeterministic, and can have up to 20ms of lag (any faster saturates the bus).

Motor controller PID works as long as you don’t use the default filtering options. They can introduce between 10ms and 20ms of group delay. For SPARK MAX, I recommend the “alternate encoder” support because you can reduce the amount of filtering (you can’t for the built-in encoder).

Drivetrains, elevators, etc.

Consistent periods improves odometry accuracy and Encoder class velocity measurements, but not by much at these speed regimes. Having a good drivetrain to begin with is more important.

Logging

Don’t do network I/O on the controller thread; it’ll drastically affect your scheduling (±0.5ms or so of extra jitter). Push to a thread-safe queue and do the logging on a separate, lower priority thread instead. It’s less of a big deal for CSV logging, but we noticed small improvements from moving that over too.

6 Likes

Good points. The only time I’ve used JNI for FRC was to use an MXP board that already had a C driver written for it, so I wasn’t thinking about performance.

1 Like

For the vast majority of teams, I don’t think language performance is ever really an issue. Java and even Python should be more than enough for most teams needs in terms of speed. What it really should boil down to is which language will be easier for your team to learn/use. I would say Java is an easier language to learn, and there’s far more teams that use it so you’ll receive more support from the community if your team runs into any issues. For that reason I would say Java would be the best bet for most teams, although if your team’s mentors and students know C++ better, then C++ might be the better pick.

2 Likes

Now that’s a team name.

13 Likes

I was more thinking band name but we’re thinking along the same lines :wink:

Those bands rarely go anyplace but they have a good time - spoken as the very occasional lighting controller guy for “The Low Ranking Snouts” back in the 80’s.

1 Like

Definitely Kotlin.


And on a more serious note, I would suggest Java unless you have a solid C++ knowledge base.

“Easily pick up C++” is an oxymoron in more than most cases. Java handles many rookie mistakes that are hard to debug in C++, especially because of lacking stacktraces. CSA/Team support for Java is much more common. Java is also easier to learn, especially if some of your students use it outside of FRC.

The slight performance margin is almost negligible for most teams. Mechanical inaccuracies will likely have a bigger effect on control accuracy than the C++/Java difference, especially if you’re using smart motor controller closed-loop features.

3 Likes

You wrote about Kotlin but I’m not sure what the point was. Some teams do in fact use it. Do you know how it compares to Java or C++?

It’s a JVM lang like Java. It can do stuff like automatic units conversions without allocating a ton of objects per second (like C++ can do), and some operations are less verbose syntactically. If you go overboard on following its idioms, it’ll get hard to read for normal Java users.

1 Like

Kotlin compiles to JVM bytecode, so it’s the same as Java in performance. Some scheduling/timing might be a bit better with coroutines, but I haven’t looked into it a lot.
Kotlin’s main advantages are a concise syntax and lot of features/constructs that Java doesn’t have - extension and free functions, singletons, named/default parameters, better functional features, etc. Inline/value classes can be used for a units library. The main disadvantages are that it isn’t officially supported in FRC (but uses WPILibJ - unlike Python afaik), coinciding with less CSA/team support; and you’re unlikely to have team members learn/use Kotlin in a non-FRC setting during their time in FRC (unlike Java which is common in school programming classes). Also, to fully take advantage of Kotlin’s features you’ll have to write some wrappers.

1 Like

This is a wonderful conversation. Thank you all.

We have used Python for a while and are in the process of switching to Java. The real reason we are looking to switch to Java is support and ease of use on student systems. Though Python is easier to write and understand, it is difficult to troubleshoot the installation errors on student systems remotely.

If you do go with a non-officially supported language, you may have difficulty getting help for any issue possibly related to programming. If you ask a CSA for network help, the first thing they may ask is what language you are using. If they do not uae that language with FRC, they may say they cannot help (this happenned to us). This can be remedied by asking clear precise questions that get to how to solve the problem not how to implement it in code, but that can take valuable time and energy to navigate at an event.

We chose Java for three reasons.
1)Header files are confusing if you do not understand how they work. Even if you do, they add another level of complexity
2)There were more complete examples and templates for Java (specifically regarding the Romi early on)
3)The syntax is easier to understand (and as an extension, Java is a bit more forgiving with types)

3 Likes

Actually, I find it’s the opposite - and that’s a good reason for Java. C++ will absolutely let you abuse your types and pointers in ways which can be useful at times, but usually create more grief than they resolve, especially for novice programmers. Java keeps you pretty much on the straight and narrow.

And as others have at least hinted, I’d much rather get a compiler error or runtime error with a reasonably useful stack trace than inexplicable behavior any day.

2 Likes

You never need pointers in FRC user code. The type systems are similar, altho I’d argue C++ templates offer better type safety than Java’s generics. Duck typing via templates is nice (the template definitions are all on the library side, mind you).

I haven’t seen one of those kinds of crashes in modern C++ robot code.

The big issue C++ has is legacy baggage. C++11 is just as easy as Java in the FRC context, but online resources still teach C++03 and new C++ users don’t know the difference. Lack of good, modern training material is a good reason to use Java over C++.

3 Likes

I’d actually question this - Java compilers have had a long time to be very highly optimized. While I don’t doubt the people behind Kotlin are clever it’s hard to beat 2 decades of optimization. (And this kids is why FORTRAN still gets use in high performance computing circles). I would bet, for frc applications, there’s no appreciable difference so I’ll admit to being overly pedantic.

Oh this is a welcome change. I guess I’ll have to give it another look, it’s been a decade after all.

1 Like

I think the reason(s) to choose C++, JAVA (or LABView or Python, etc.) boils down to a few factors:

  • The language are your mentors most comfortable with. These are your long-term resources that can guide students year after year. If they can show students the best way to utilize the advantages of the language. It is a big win for the students if they can learn why/how to do certain things and not just get something working. Plus, the robot will probably work better.

  • The language the current students are familiar with or want to learn. They are going write the code, so if it is something they either know already or want to learn, they will spend the time to get good at it and ask questions to learn (this is why mentor knowledge is key though, because if they can’t answer questions, you find less the optimal practices being utilized). Having the discussion with the student that what you just wrote will work, but if you approach a slightly different way it will be much faster or will use less memory. Or maybe you consciously choose a way that will be not quite as fast or uses a bit more memory because you want the code to be understandable by everybody and they are not there yet.

  • The next thing, is how self sufficient do you think you will be at a competition when something breaks. If you are not confident that you can handle it yourself - stick with one of the 3 formally supported languages – though JAVA is probably your best bet at finding help. Though – I’d contend someone that knows the WPILIB stack for either JAVA or C++ can probably help with the other language. I few years ago, we had a student that spent much of the competition helping other teams – most using JAVA – get autons working – we dubbed it Austin’s Auton Rescue. LabView seems to be more spread out – some areas have a lot of teams that use it and other areas have very few. Unfortunately, this limits the ability to get help – I know I have helped LabView teams before because there were no other LabView teams and the CSA didn’t really know it either, but I am far from a good resource as it takes longer to spot/resolve issues.

We have used JAVA and LabView in the past. We’ve been using C++ for a number of years. We had done a comparison many years ago after a LabView season where we had limited LabView knowledge and the students had little interest in using LabView. The following Summer, we re-wrote the software for the robot using both JAVA and C++ (we also compared the old command based structure with just a straight iterative robot). The C++/JAVA syntax wasn’t that different, so we felt like there wasn’t a clear advantage. We were going to go with C++ because we saw better performance and more consistent memory usage on the RoboRio. Then in the Fall, we had some new students who knew JAVA for classes, so we decided to use (they were already going to have to learn the WPILIB environment, so being familiar with JAVA was viewed as a way for them to contribute sooner). The following year when these students graduated, the remaining students wanted to go back to C++, so we did and have been using it ever since.

I think the more important thing is not the language, but rather how to design the code to make it easier to debug when there are issues and allow multiple students to contribute.

I’m not sure what people are talking about when they refer to not getting compile errors and runtime errors, because we see stack traces when there are runtime errors (and compile errors). Maybe it is because we generally use the latest C++ conventions that save you from yourself.

I don’t think C++ is for everyone as I would go back the other criteria listed above. I know I’ve contemplated recommending going back to JAVA only because we now have FTC students coming up that already know JAVA – but we have found that they pick up the C++ pretty quickly. So, knowing 2 languages is probably better for them in the long run.

2 Likes