No problem. We'll agree to disagree.
As for the garbage collector, yes, I think it has a severe design flaw for essentially the same reason. You can "construct" an object whenever YOU say so, i.e. you have full control over that, but you cannot "destruct" the object whenever YOU say so. Garbage collector decides when that will occur, i.e. once again the "start" and the "stop" are not controllable AT THE SAME LEVEL.
So, imagine you decide to use java for your real-time app, say your new X-fighter (airplane), to control the ailerons, elevator and rudder. (I used to be a flight instructor, so I know a bit about this particular "app".) You, the pilot, decide to input some left aileron to miss that radio antenna that someone suddenly put up in front of you. Oh, S*^#!
Right at that same second, the garbage collector, knowing more about what need to be done when, than the you, the pilot, you who are now frantically moving the unresponsive yoke back and forth...and knowing more than the poor java app programmer, who did the best she could by giving the almighty GC "hints" in the form of System.gc()'s that the GC, by design, is free to ignore. (Right? I was taught that System.gc is not a guarantee to collect at that point, right?)
The GC, in its infinite wisdom...wisdom that Gosling or someone at his level of knowledge coded into it (maybe he was in a hurry and didn't have time to write a really good GC? If so, that's forgivable. Been there myself many times
)..., anyway the GC decides that NOWS the time to collect the 100,000 objects that have been growing memory, objects it didn't have time to collect before, because so many objects were being quicky created as the pilot desperately attempted to maneuver through that bad thunderstorm a couple of minutes ago.
This, that the GC (the jvm programmer) knows more than the pilot (the user) is essentially one of Alan Cooper's points in his book, and yeah, I'd call that a "design fault". Once again, this isn't just me saying this. See "Garbage Collection": http://www.cs.virginia.edu/~mpw7t/cs655/nojava.html
Note the date in the article above, because the good news is that it looks like, on this one, they've decided to fix the flaw: http://java.sun.com/developer/technicalArticles/Interviews/Bollella_qa2.html http://www.onjava.com/pub/a/onjava/2006/05/10/real-time-java-introduction.html
(Again, note the article dates above.)
Now, if they'd undeprecate the .stop(), I'd be a happy coder, and I'd love to know the technical reason that they can't, coz then maybe I could work around the crashes it's causing me in Eclipse.
Now, why should YOU (the java community) care about any of this?
Because Mother Nature loves efficiency, i.e. because if you don't, then some other language, a new, more elegantly designed language with less "scar tissue" (see Alan Cooper book above), a language that was not initially designed to run your toaster oven, a language written by some team with no significant investment in java, is going to come along and kick Java's a**. This would make me very sad, coz I've now invested so many years in it.
So, now that java's been open-sourced by Sun, will someone please, please, please undeprecate the .stop()...and make it work as it was originally intended?