This is a debate that has been going on since we've had a choice of multiple languages to choose from. There really isn't any "right" or "wrong" choice or one being better than the other when it comes to this particular environment. It's matter of preference, skill sets and risk.
Let me share a little of my background so you may understand where I am coming from with my analysis for the choice of language. I'm the Mentor for my Team for both Software and Electronics. I've been a low level ASSEMBLY language programmer my entire career (33 yrs). I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview.
However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.
#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.
Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.
#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistake on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?
My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.
I have had this very issue in my professional career with software and hardware products that are "supposed" to work together. Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.
So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.
I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.