We could instead send small robots that can build anything on site when arrive, even self replicate themselves. We would call them 'replicators'.
What could go wrong?

Found this on wikipedia:

http://en.wikipedia.org/wiki/Faster-than-light#Faster_light_.28Casimir_vacuum_and_quantum_tunnelling.29

+1 to parent.

I used ecipse, doxygen, nm, dot to understand code. Understand, control, refactor, repeat is the main method. The details vary from project to project.
If something is too complex to understand try to isolate it. Maybe you will need to replace it later. Modular code is your friend.
Very important: make small changes and commit them often so you can backtrack if you make a misstep. Use your favorite version control tool. I used hg+svn but use whatever you like best. Prefer to commit atomic changes, for example single changes in functionality, so you can undo one thing without breaking another.
I don't use source navigator since more than 10 years but I don't think you'll need it with Eclipse+doxygen.
FIrst add documentation and small changes. I use to add doxygen comments and convert old K&R code to ansi c o c++ first to gain type checking without changing any semantic.

From TFA:

Italian last names are pretty common in Argentina.
And as others pointed out Pavarotti has already died.
As a joke was pretty lame.

I would refute you but I have no energy.

There is an ongoing project for development of a python front end for GCC. I don't know its current status but it most be experimental.
Also there is the Java implementation of Python, JPython. By virtue of running over the JVM Just In Time compiler Python code gets compiled to native code in runtime eventually.
I can understand your point about C but the lastest C++ compilers are looking real good for the same job, even if you limit yourself to a subset of C++. I have been converting some old libraries and small apps from C to more modern C++ using mostly strings and maps and I can report that is much safer and readable than C. Just using std::string to replace char*s have been a pleasure in security gained, even if std::string is not very nice.
Practically hadn't needed pointers in most cases.

Thank you for the link! that fact alone -easy tz database update independent of the jre/jdk release- makes Joda-time very valuable.
I always wondered why there isn't such a mechanism for Java.

If your app in java 1.4 uses swings it may hit some bumps in the migration to java 5 to java 6 to java 7. I have a real case of that. Mostly is a case of loose programming for swing in 1.4 that got stricter in later versions.
Surprisingly going directly from 1.4 to 7 seems to work fine. Only god knows why. I can't find anything on the release notes that explains it.

I'm aware of that. My question pointed specifically to the timezone implementation. If the relevant parts are open source it should be not hard to write an alternative utility.

Bytecode is but a concept and there are many different, incompatible implementations. Like programming languages and compilers.

Sorry, no. Perhaps it was time 10 years ago if ever. Now is too late. Even Google is using less Python these days.

How this impacts openjdk? does it uses the same Olsen timezone data or has another tool for updating it?

I don't know but I suppose it was for portability across different operating system.

Indeed. Finally someone talking sense at Slashdot.

Free speech? Mmmh if someone could monetize on that... Just saying...