Java vs C++

[LeelandS]

Greeting Chief Delphi community,

As the build season comes ever closer, 1126's software team has a decision to make: What language do we use to program the robot? It's come down to Java or C++. So, in addition to what we've discussed withing ourselves, we are hoping to get some feedback from the Chief Delphi world.

We're looking for the pros and cons of using Java vs C++.

Please and thank you to anyone willing to help us,
Leeland Somerville

[Robototes2412]

Pros for Java:
1. Garbage Collector
2. no pointers

Pros for C++:
1. More control
2. Pointers (a two-edged sword)

[Jon Stratis]

This question seems to come up every few months. We could go through a long list of pro's and cons about each language, but it won't tell you what you need to know. When it comes to 99% of the work a robot needs to do, there's really no difference between them. Performance is going to be more or less equivalent unless your doing a ton of graphics processing from the camera (and even then, the difference won't be terribly large).

In the end, the decision should really come down to what your team wants to do. The biggest advantage you can have with one language over the other is prior experience - If you've used Java in classes in school, that'll be a lot easier for you to work with, because you'll already understand how things work. While C++ is similar, there are some big differences that can cause some serious headaches.

[EricH]

What are you more familiar with? If you're more familiar with one than the other, go with that one and learn the other if possible.

(And the obligatory "don't forget about LabView", but I'm fairly certain you've got good reasons for not going that road.)

[Alan Anderson]

Originally Posted by EricH

What are you more familiar with? If you're more familiar with one than the other, go with that one and learn the other if possible.

On the other hand, it might actually be more fun to go with a less comfortable choice from the beginning. Don't just consider what you already know; think about how easy it will be for people who don't know anything yet.

(And the obligatory "don't forget about LabView", but I'm fairly certain you've got good reasons for not going that road.)

The reasons might seem good, but they probably aren't great.

Among other things, keep in mind that LabVIEW tends to be slightly better supported by the makers of the cRIO, and that using it is presently the only official way to write your own Dashboard program.

[apalrd]

Search is your friend. This has already been discussed numerous times.

since Java and C++ have been covered, how about LabVIEW? It is my language of choice, for FRC robots.


LabVIEW:
Graphical (Some like it, some hate it.)
Great amount of feedback data (The ability to probe any variable at any time is kinda handy, as is the ability to send two-way debugging data in real time when not running in competition mode)
Ability to update data while code is running (You can change cal points while the code is running)

[davidthefat]

http://www.youtube.com/watch?v=Ps8jOj7diA0

That talks about the difference between C/C++ and Java. I think it was this one, might have been the Abstraction lecture.

[JesseK]

Originally Posted by Robototes2412

Pros for Java:
1. Garbage Collector
2. no pointers

Pros for C++:
1. More control
2. Pointers (a two-edged sword)

Technically every reference that's passed around in Java IS a pointer under the covers. The big difference is that the developer doesn't have to worry about pointers vs. pass-by-reference (i.e. whenever you see a '&' in front of a variable name that represents a large quantity of data). Java handles it all; C++ allows more control.

In the FRC world, I'm not sure what the difference is. In industry, Java is hardware and operating system independent so long as a JVM exsists (Sun/Oracle provides the JVM), where a C++ must be compiled specifically for a platform and even a specific version of the platform. This means that Java developed for Linux typically also works in Windows (ignoring any full-path file system stuff). It also means that C++ can go on more systems than Java since Sun/Oracle doesn't create a JVM for all platforms (such as embedded platforms like an Arduino).

[Ether]

Originally Posted by davidthefat

http://www.youtube.com/watch?v=Ps8jOj7diA0

That talks about the difference between C/C++ and Java. I think it was this one, might have been the Abstraction lecture.

It wasn't the one you linked to.

[Ether]

Originally Posted by JesseK

Sun/Oracle doesn't create a JVM for all platforms (such as embedded platforms like an Arduino).

I wonder if there would be a market for Java cross-compilers for popular microcontrollers.

[taichichuan]

The JVM tends to be rather memory hungry. The reason there's no JRE for the Arduino is that Java simply takes too much RAM to run on the memory footprint of an ATMega part.

There are some Java implementations that are lean. The Dalvik VM found on Android platforms is one example. However, that VM uses a just-in-time (JIT) compiler (Android 2.2+) and a register-based VM rather than Oracle's stack-based VM. The register-based VM is more efficient and better suited to JIT compilation. However, these are the very reasons that Oracle is suing Google. Also, Oracle seems to be backing out on their support for open source Java solutions (just ask the Apache folks). So, the future of Java as anything other than a proprietary platform is in question at the moment.

On the other hand, C/C++ has been a standard for embedded development for almost 30 years and doesn't seem to be going away any time soon. In fact, most of the JVMs are written in C/C++. If limited memory footprints are in your future, then Java is not the solution.

All that being said, Java tends to work just fine for FRC robots. You're typically not running long enough for the garbage collection cycle to become an issue, and 64MBs of RAM is really quite a lot for many applications. The other advantage of Java is that it's the language used on the AP exams. So, many of your team may already have some Java experience.

I think it was summed up earlier in this thread, you go with what your team may already have experience with. C/C++ execution is arguably faster than Java, but FRC competitions are typically not won or lost on a microsecond scale. The additional complexity of C/C++, while it may make them arguably more employable in the embedded marketplace, can be daunting for first-time developers.

HTH,

Mike

[Ether]

Originally Posted by taichichuan

The JVM tends to be rather memory hungry. The reason there's no JRE for the Arduino is that Java simply takes too much RAM to run on the memory footprint of an ATMega part.

Yeah, I know. I was talking about a cross-compiler (with a smart linker), not a VM.

Probably not a big enough market to justify the development expense. Maybe there are some legal issues as well.

[Gdeaver]

This isn't for FIRST but, Microsoft has the .NET Micro Frame work. I've been playing with these products.
http://www.tinyclr.com/
C# is similar to java and It's nice to plug a joy stick into a controller and have a device class at your disposal. On the other hand things that require interrupts and timing like quadrature encoders are more of a problem. Playing with a 70 mhz arm 7 with out absorbing over 1000 pages of chip manual is nice. Visual studio express C# is free and not to bad a environment. This also allows people who have no micro controller experience but .net talent to dive into micro's with some familiarity.

[Foster]

There have been lots and lots of posts about the C/C++ vs Java, the search bar is your friend. I've been in the software business for a long time, so in the last decade I've probably read 1.2 million articles and posts on the same subject.

Given a choice of all the software out there at this point I'd do either the Lua or Python implementation, most likely the Lua one since I have experience with Lua in other applications.

Reasons: the long download and build times for Labview, the concept of doing a FTP download and having code ready to run is good.

Being able to write short modular code helps. I've never been happy with the way Labview code is intertwined.

All I can say for sure is "Know the Language You are Writing In Before Build Season Starts". January is not the time to learn a new language, new environment, new way of doing things.

[Ether]

Originally Posted by Foster

in the last decade I've probably read 1.2 million articles and posts on the same subject.

329 articles per day, 7 days a week, 52 weeks a year, for 10 years