1

I apologize in advance if this question sounds presumptuous. I'm fairly new to this. So here it goes . . .

I've been researching the "java thread stopping" issue for a while. I read many articles on stackoverflow, and most of them come to a conclusion that thread stopping is very awkward in java. Some good ways include:

  1. Using join (this answer got 87 upvotes) and wait until a thread finished.
  2. Set a volatile flag to signal the other threads. This answer got 113 upvotes
  3. Many recommend Thread.interrupt() and later check isInterrupted
  4. Some recommend using a high level API like ExecutorService. But that shutdownNow method does not give any guarantees, and counts on that isInterrupted boolean

But neither of the above methods allow an immediate thread stop. For example, if a program is running some SQL and waiting for an external database respond, then ALL of the above method will "humbly wait" until that SQL finishes. So the stopping is NOT immediate at all. Only when that SQL finishes (which may take hours), will the program check for isInterrupted or other flag, and then stop

Here is the punchline . . . I know Eclipse is written in java according to this stackoverflow answer. And whenever I click that red stop button , Eclipse will stop my application immediately. I presume it is NOT using Thread.stop since it's deprecated. But I it can't possible be using those method recommended on stackoverflow. How does Eclipse manage to stop threads so fast?

Community
  • 1
  • 1
john
  • 647
  • 5
  • 23
  • 53
  • Not really: I have seen far too often that eclipse keeps spinning built tasks in the background forever (we have huge projects ... and especially while we were still on SVN it was far too often that I had to kill eclipse to make it stop spinning ... and all the "stop now" clicking within eclipse didn't achieve anything) – GhostCat Jul 22 '16 at 14:26
  • 3
    You're killing a _process_ when you press the red button, not just a thread. – Solomon Slow Jul 22 '16 at 14:29
  • But that process is a `Thread` to Eclispse isn't it? It's a process for me, but from Eclipse's standpoint, it's a `Thread` – john Jul 22 '16 at 14:31
  • @john https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html – Gimby Jul 22 '16 at 14:36
  • @john Not necessarily - eclipse could just spawn another process to run a JVM in there, to the required things, for example to compile some source code. Of course, a process means a lot of overhead, and no easy way to communicate back and forth, but as said: it can actually be killed. – GhostCat Jul 22 '16 at 14:37
  • @Gimby I see the link contains "8". Is this specific to java 8. Because I couldn't compile 8 with a target of even 7. – john Jul 22 '16 at 14:37
  • @john The 8 means I linked to the javadoc of the most recent Java version, nothing more. Javadocs of the JDK state since which version a class is available - since the very first in this case. I have no idea what *"I couldn't compile 8 with a target of even 7"* means. – Gimby Jul 22 '16 at 14:42
  • @Gimby this is windows command line: `$ javac Test -source 1.8 -target 1.7` `javac: source release 1.8 requires target release 1.8` – john Jul 22 '16 at 14:47
  • @john That is irrelevant. The documentation clearly states that `java.lang.Process` exists since JDK 1.0. – E_net4 Jul 22 '16 at 14:52
  • @Gimby apologies. I see what you mean. It makes sense thanks – john Jul 22 '16 at 15:17

1 Answers1

7

When you run a Java program from within Eclipse a completely new JVM is created in a new Process to run the program. A process is not the same thing as a thread.

Within Eclipse the process is represented by the java.lang.Process class. Eclipse calls the destroy() method of Process when you stop the program.

So what Eclipse is using for this is nothing to do with threads.

greg-449
  • 109,219
  • 232
  • 102
  • 145