Java VS C++ || The Final Decision

Which does your team use, Java or C++?
I have searched through these forums and google for this answer and it is very wishy washy.

If you want leave why you use it but vote for either.

You forgot Labview.

(I’m not on a team, except as an alum, so I can’t answer… but I would guess that you’ll get a pretty even split between the three.)

Java. Our school teaches Computer Science in Java, so naturally the programming team liked the idea of using Java to program the robot, since we didn’t already have a base in Labview or C++ anyway (2010 team). Though I ended up being the only programmer in the end… so Java definitely was a good choice because I’d hate to be programming a robot solo in a language I’m not already familiar with.

C++. We’ve had 2 new programmers doing all of the work since the new control system came out and we’re both already competent in C++, so we stick with that

LabVIEW is an irrelevant language here!

C++ I find Java to be a language that is similar to C++ but with traning wheels

How is it irrelevant? It is a programing language with the same, if not more potential than the other programing languages. Our team uses LabView.

If I had to choose between C++ and Java, I would choose C++ for robot programming:

  1. The gigantic advantage Java has over C++ is that it can make pretty GUI’s. However, that is completely useless in cRio programming as there is no GUI interface.

  2. This year, Java was on its first year and C++ was on its second, however the old control system has been using C since 2004. C/C++ is much more proven and tested in FRC robotics as of now then Java.

  3. I already know C++. I don’t already know Java. I also know and like LabVIEW.

You sir make a very good point.

The makers of the cRIO would probably disagree about that. The FPGA (the part that does all the “real work”) is programmed using LabVIEW. So is the provided FRC dashboard application.

For what it’s worth, Team 45 uses neither C++ nor Java.

I apologize for disregarding LabVIEW. Wasn’t my focus.

  1. Trust me when I say that Java is much more capable than that. Desktop Java, as in version 1.6 with standard libraries is considerably more capable than vanilla C++. Even with the limited version you get on the cRIO (Java 1.3 with J2ME libraries) you can still do plenty. I have plenty of examples if you’d like ;).

  2. With a new and different environment (the cRIO) you can hardly call it ‘proven’. The (completely) new C libraries only have a year’s head start on their Java equivalent, and having used both, I can say that both work very well.

  3. A valid point, but I’d certainly recommend you give it a try- in most cases the syntax is identical or even simpler than a C/++ equivalent so the learning curve is actually quite small.

That doesn’t make it good. Trust me when I say that’s one of the most inefficient programs I’ve seen in a long time. I honestly feel bad for the processor on our XO laptop while it (the dashboard) is running- the CPU usage shoots up to 100% rendering something that should barely take any CPU at all.

My opinion on LabVIEW: It may make coding convenient or easy, but that doesn’t make it better than other tools.

As much as I like C++, Netbeans was an easier IDE to use.
Some of the things that made it easier were:

  • Integrated Netconsole, Serial comms without a long cord, (connecting to the remote server never worked for us)
  • Automatic reboot on download, when not using the debug mode, this saved lots of time
  • Automatic file uploader, uploads the correct program file without going to a configuration page even when changing projects

Though, it seemed that there was a memory leak somewhere which would limit us in how many times we could upload / minutes open before we would have to restart netbeans.

And library support was a little lacking this year.
Only the vision libraries that were needed to get the vision tracking were ported.
To access any other parts of the NIvision libraries, JNA (Java Native Access) was required, (Writing a method in C++, compiling it in windriver, and then uploading it)

CAN support for the closed loop modes (current, position, speed) for java was the last language implemented, with a gap between Labview and C++.

But, even without all of the libraries, Java was perfectly capable language for programming the cRIO, and FRC robots.

My biggest complaint with Java on the cRIO is that they ported a non-realtime version of Java, instead of a realtime version.

I would be overjoyed to use C++ for robot programming,


Wow, i was angry.

could someone please <code> a makeFile from the C++ stuff? I think I can get C++ working on linux if i have a makefile.

I believe that both C++ and Java are equally capable languages for the type of robot programming that we are doing in FRC. So what it comes down to is a matter of personal preference.

I personally have a dislike for all interpreted languages, it just seems like a clumsy to me. I have spent about the same amount of time working with C++ as I have with Java, and I personally find Java a more frustrating language to program in. I understand that part of the goal of Java was to force an object oriented design of the programmer, and while I like this concept, I dislike how restrictive it makes the Java language.

I have had teachers that raved about Java, saying it’s the best thing since sliced bread, and while I respect my teachers… I have to respectively disagree. Java is possibly a good learning tool, but for making clean, efficient programs, it’s just not the thing for the job.

I would also have to disagree about the strong point of Java being it’s GUI abilities. If you take and C++ compiler and add on a nice graphics library like QT, Java is no match. The language is just all around clumsy.

Unfortunately it’s not quite that simple. As it’s being cross-compiled you’d need a version of GCC for the correct architecture (PPC) and then package that in a format the cRIO can understand. Not to mention uploading that to the device…

I’m fairly certain the uploading bit is just an FTP server, but most of the process for deploying that code is hidden away. I have a feeling they aren’t doing anything too fishy behind the scenes, it’s just that the documentation for what they’re doing doesn’t seem to exist. Otherwise it really wouldn’t be that hard to do.

Right now, though, the easiest way to do FRC dev on Linux or any of the *NIX OSes is to use the Java environment. No complaints from me though, NetBeans is a dream to use :D.

I have found that its “restiveness” is actually one of its strengths, especially with regards to FIRST. C and C++ take longer to debug, and as has been discussed in other threads, the biggest restriction to programmers is the time they get with the robot, so being able to debug quickly is critical.

Java is certainly a pig of a language, but I also like using it for backends to an GUI. I use Flex (which is also a pig) but ports nicely now with Java since flash builder 4 and blazeds. I really like OO, especially from an architecture standpoint and flex brings OO development to web and desktop dev. So even though it is a pig, it is easier to debug and I find it easier to build with.

Then again from my experiences, people who love c and c++ hate flex.

(lets not get started on steve jobs… :wink: )

I don’t really want to get involved in these food-fights about languages, but since LV came up, let me just clarify that the CPU usage of the dashboard is not something that you can blame on LV. Blame me instead. I made a mistake and the LV UI was dealing with overlapping controls the best way it could, doing offscreen drawing and extra redraws. That is what used the excess CPU.

Greg McKaskle

Netbeans works on Ubuntu and you can probably find the plugin for FRC for it.