Java versus C++

[rogerlsmith]

From my experience mentoring teams using both C++ & Java, I have not seen any kind of performance issues. If you already have experience in Java, go with that.

I have been posting some simple Java programming tips on my blog. Feel free to contact me if you have any questions.

[RoboMaster]

Originally Posted by rogerlsmith

If you already have experience in Java, go with that.

Well said Roger. Consider this advice when looking at your options, it is a very good point. It always comes up in discussions like this.

[Jon Stratis]

The statement "Java is slow" has been around a long time. And at one point, it was true. When Java first came out, it was slower than other languages like C. But there have been a TON of optimizations over the past 10+ years that simply make that statement not true in most cases. In fact, due in a large part to memory management, C++ can be slower than Java (Pointers are time consuming to handle for C++, malloc sucks, performance wise. You don't have those problems with Java).

for a young programmer like yourself, you have a couple of options.

1. You can go with what you already know (Java) - that will be the easiest and surest way of producing quality code for your team. The additional benefit of extra exposure to the language through the team will also help you with your classwork. Looking towards the future (aka college), you'll most likely being using Java for a lot. I know my old school has switched many classes over to Java in the past 6 years or so. Having a deeper understanding of that language now will only help you with your classwork in the future.

2. You could go with a different language for a broader experience. While this will probably be more difficult and time consuming for you, most programming jobs generally involve multiple languages - and having a broad exposure will help in the long run. For instance, right now my job requires me to know HTML, Groovy, JSP, Java, SQL, PL/SQL, and C (i think that's everything...). Additionally, learning multiple programming languages helps you to understand the basics of how languages, in general, work. You don't need to deal with pointers in Java, but working with them in C will dramatically increase your understanding of how computers work.

One last thing to consider: What support do you have? Do you have any programming mentors? do they have a preferred language?

Our team ended up going with Java for two reasons - first, the students were familiar with it from classes at school. Second, the mentors knew it better than C++ and could help them succeed better with it.

Another team we work closely with made a different decision. They went with Labview (i think), and ran into some big problems late in the season that their mentors (who were experts in Java) couldn't help much with. Having a safety net of knowledgeable people close at hand isn't something to ignore.

[Ether]

Originally Posted by eagle33199

... C++ can be slower than Java (Pointers are time consuming to handle for C++, malloc sucks, performance wise. You don't have those problems with Java).

Can you please provide an authoritative reference, or experimental data, to support the claims that:

1) properly-written code using pointers in C++ runs slower than functionally equivalent code written in Java

and

2) properly-written code using malloc in C++ runs slower than functionally equivalent code written in Java

Thanks!

[AustinSchuh]

My understanding is that the JVM that's been ported to the cRIO is the squawk VM, which is not a real-time VM. While you might have your own opinions about the importance of a system being real-time or not, that was something that played into our thought process.

[Ether]

Originally Posted by AustinSchuh

My understanding is that the JVM that's been ported to the cRIO is the squawk VM, which is not a real-time VM. While you might have your own opinions about the importance of a system being real-time or not, that was something that played into our thought process.

Could someone knowledgeable about this please weigh in on this?

It was my understanding (perhaps incorrect) that the 2010 FRC Framework for Java was written in such a way to use the underlying vxWorks RTOS to handle the realtime aspects, thus mitigating the lack of true built-in realtime support in the VM. Not?

[EricVanWyk]

Originally Posted by AustinSchuh

My understanding is that the JVM that's been ported to the cRIO is the squawk VM, which is not a real-time VM. While you might have your own opinions about the importance of a system being real-time or not, that was something that played into our thought process.

Can someone explain why JVN is squawking in real-time? I thought John VNeun was more of a mechanical guy.



I'm sorry, but I can't help but misread JVM as JVN, at least in an FRC context.

[Greg McKaskle]

While I'm pretty sure I can build a car that operates more slowly than a bike, or find a turtle that outruns a hare, I'd caution against drawing general conclusions from such benchmarks.

One of the fundamental underpinnings of computer science is examining a problem and determining the inherent complexity, looking at a solution and determining the way it scales based on it's inputs, and getting beyond qualitative terms such as fast and slow.

You have choices as to which tools to use, and I wouldn't personally base the decision on runtime performance. Instead look what will support agility, productivity, and reliability. Also consider what enables your team to learn new things and to pass the knowledge on to the next generation of your team.

Greg McKaskle