Are you looking to simulate the cRIO or a robotic environment?
Palardy's got it right. You can just "stub" out the entire cRIO as this is "only a small part of robot programming." I would even say VERY small part if your robot does only half the stuff the Killer Bees do.
To do this, just create one "hardware interface" subroutine/class and make a call to it every cycle through your robot code. Or stick it in another thread with a timer or however your team (and other teams who do not use LabVIEW) do it. The trick is to group all of your cRIO specific code in there... I'm not sure how the Java and C++ environments work, but you probably also have to create a surrogate Java class for the "main" process because that won't run in the PC environment either? That should just be a matter of creating a mostly empty class with the same interface and included using a different header file with the same class name.
This kind of partition in your robot code is HIGHLY recommended. It allows you to separate your robot control algorithms from the hardware interface and VALIDATE the hardware specific portion (polarity, units, encoder functionality, low level controls, etc.) INDEPENDENTLY. If you have a simulator, you can VERIFY the algorithms as well. You should have your SW team create a HW checkout program and NEVER test code on the robot unless it passes. This saves a lot of headaches and is a useful diagnostic tool for the entire season.
Once you have the partition, you can stick any kind of robot model you want (simple or complex) inside the stub for execution on the PC. Of course I highly recommend the Team 302 trainer VIRSYS
http://www.virsys.org.
If you can write a UDP send and receive routine for floating point arrays (we already have one that's close in C# / javascript) then you can get VIRSYS running for C++ in short order. The first (now second) release is designed as an instructional tool.
How do you plan on simulating the Joystick, other control boxes, and driver's station? This is not the cRIO. LabVIEW makes this easy with lots of virtual dials, switches, charts, and simple recognition of joysticks (limited to first 3 axes and 16? buttons). You can add that to the tool chain as a "driver station" stub in exactly the same way (just borrow the setup and UDP communications already available in the VIRSYS LabVIEW distribution).
I don't really know Java. However, if you are willing to give it a try, I can create a quick and dirty C++ example of this that should convert without too much difficulty.
Great question and good luck!!