I've figured out why eclipse seemed to be a pain in the ass initially. Its Eclipse 3.1.0 running on Mandrake.
What happens is, if you kill it through the Session/Shell console you started it in, via Ctrl-C, the next time you try to start it, in the workspace you were in, it will just hang.
killall -9 java won't kill any java process
(there aren't any indications showing java is running in any case ps -e neither are there any instances of eclipse related process).
I wonder if this is an eclipse problem or a Mandrake problem. My thinking is that closing abruptly doesn't write the final state of eclipse to the appropriate file consisting of initialization Metadata - that's just a guess, hence when you re-start eclipse, it tries to identify the last state it was in and cannot find it.
Solution: If this is indeed the case, why not have a second log file for the Metadata that is written the first time eclipse is exited normally. This file should be a step in behind the normal metadata file and move up in terms of previous state every time it eclipse is closed properly (I mean supposing there is constant power failure).
If eclipse takes too long to startup, the normal startup file is replaced by the first metadata file for that work place hence you only step back to one state as opposed to eliminating the wholestate and restarting.
I don't know if this makes sense, but that's my take on it. Coz a lot of us sometimes always get absent minded and just simply hit Ctrl-C if we are already in the Console and want to kill the app.
My apologies its more so an annoyance than a bug. Nevertheless can't all those highly paid Engineers come up with a way to overcome this (as mentioned in the previous post).
You simply nuke the contents of the .metadata folder then restart eclipse with the -margs clean option.
Unfortunately you'll have to redifine your source and development environment which takes a fair deal of minutes if your working on large scale systems - as I am.
Previous Topic
