Alex, looks like you haven't bothered to even learn Java and therefore, wouldn't have any idea on how to code in other languages too; Java Rocks.
Java Thread dumps are often cause by inexperienced coders like yourself!

Interesting and exciting news about JAVA.yah, JAVA is conquering all.....

Hey, SYS-CON editors where is your new headline story
"Java DON''T RUN NASA Mars Rovers. Java Anywhere is a Fiction."?

To set the record straight... There is absolutely no Java running onboard the MER rovers. The flight software is all written in C for vxWorks, with possibly a tiny bit of assembly language. The MER project does run Java in several key places on the ground. The ground data system has software written in a variety of languages. I''ve seen Fortran, C, C++, Perl, Python, and Java.

"The U.K.''''s Beagle 2 apparently was running .Net. One can imagine it up there on Mars, showing a Blue Screen of Death." :)
No Guesses. Java proudly crash and producing thread dumps. Java don''t need those "blue screens", it proudly crash without them.
The only strange thing - why statements "Java on the Mars" and "Software crashed" always appear in different press releases. Why not proudly announce - "Java crashed on the Mars", or "Write once, crash everywhere".

Being as risk adverse as JPL is, I''d be surprised they would put something as complex as a Java virtual machine on top of a flat memory operating system, even though this configuration can be found in many embedded computer environments. It is bad enough that memory corruption and other hardware issues can bring down a flat memory operating system much more easily than a memory protected operating system where the application effected by the hardware can be contained and diagnosted by the stable, secure os kernel. But to add in a complex Java virtual machine in there too is asking for trouble.

Raj Upadhyaya, you beat me to it. If that is Java''s version of a BSOD, it appears more complex. And Greg, its "Write once, tweak everywhere".

SCJP

Last message received from Mars Rover.

Full thread dump:
"Thread-5" (TID:0xee703b78, sys_thread_t:0xee261db8, state:R) prio=5
mythread.stopper(exec3.java:10)
mythread.run(exec3.java:16)
"Thread-4" (TID:0xee703bb8, sys_thread_t:0xee291db8, state:R) prio=5 *current thread*
mythread.stopper(exec3.java:10)
mythread.run(exec3.java:16)
"Finalizer thread" (TID:0xee700220, sys_thread_t:0xee2c1d b8, state:R) prio=1
"Async Garbage Collector" (TID:0xee700268, sys_thread_t:0 xee2f1db8, state:R) prio=1
"Idle thread" (TID:0xee7002b0, sys_thread_t:0xee3c1db8, state:R) prio=0
"Clock" (TID:0xee700088, sys_thread_t:0xee3f1db8, state:CW) prio=12
"main" (TID:0xee7000b0, sys_thread_t:0x693a0, state:CW) prio=5
exec3.main(exec3.java:32)
Monitor Cache Dump:
mythread@EE703BB8/EE74E190: owner "Thread-4" (0xee291db8, 1 entry)
mythread@EE703B78/EE74E270: owner "Thread-5" (0xee261db8, 1 entry)
(0x693a0):
Waiting to be notified:
"main" (0x693a0)
Registered Monitor Dump:
Thread queue lock:
Name and type hash table lock:
String intern lock:
JNI pinning lock:
JNI global reference lock:
BinClass lock:
Class loading lock:
Java stack lock:
Code rewrite lock:
Heap lock:
Has finalization queue lock:
Finalize me queue lock:
Monitor IO lock:
Child death monitor:
Event monitor:
I/O monitor:
Alarm monitor:
Waiting to be notified:
"Clock" (0xee3f1db8)
Sbrk lock:
Monitor registry: owner "Thread-4" (0xee291db8, 1 entry)
Thread Alarm Q:
sys_thread_t 0x693a0 [Timeout in 9997374 ms]

Hmm. I''ve seen Dr. Gosling speak several times in the last few months and he always talks about his involvment with the Mars Rover project. He also always says that while Java is employed extensively by the ground systems there''s no Java onboard the rover itself. Have we gotten a little ahead of ourselves here?

More evidence of "Write once, run anywhere".

The U.K.''s Beagle 2 apparently was running .Net. One can imagine it up there on Mars, showing a Blue Screen of Death.