All the Java IDEs seem to suffer from a related problem: if one is left
open and idle for a while, it freezes and gets reported by the OS as
"not responding" for a significant time (usually several full minutes)
if you then switch to it and try to start using it again.
Eclipse and Netbeans, in particular, are both guilty of this behavior.
Even the "lightweight" Clojure IDE clooj does it (worse, it sometimes
*crashes* if it was minimized -- it will grind for a while not
responding, and then instead of becoming responsive it may instead just
disappear without so much as a word of explanation. If you look in the
jar's directory, however, there'll be a file there with a name like
hs_err_pid7004.log saying something like
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d0b6b30, pid=7004,
tid=7040
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode, sharing
windows-x86 )
# Problematic frame:
# C [awt.dll+0xb6b30]
#
# If you would like to submit a bug report, please visit:
#
http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x05062800): JavaThread "AWT-Windows" daemon
[_thread_in_native, id=7040, stack(0x05750000,0x057a0000)]
and then a bunch of miscellaneous junk. The details will vary depending
on JVM version and operating system, but it seems to be a bug in AWT
provoked by deminimizing a Frame.
To my knowledge, Eclipse and Netbeans don't share this problem, but do
share the hang-on-suddenly-being-focused-after-having-been-idle bug. The
clooj crashes also never occur if it was not minimized but just left
idle, though the hang still occurs. If it was minimized, the hang may be
followed by the crash or by the application becoming responsive again,
seemingly at random.
All of the hangs show a low level of CPU use and a low level of I/O use
in ps/tops/etc. type tools (or ProcessExplorer, on Windows). So it's not
a busy-loop or heavy I/O making it unresponsive; instead the profile of
CPU/IO use is more like what you'd expect if the EDT was blocked on a
monitor waiting for a lock to be released somewhere. Possibly another
AWT bug, then -- in which case it may be endemic to any GUI app coded in
Java.
Since Swing apps (clooj, NetBeans) and SWT apps (Eclipse) both exhibit
the problem, the problem is likely to exist at the AWT level (or lower)
rather than in either Swing or SWT.
The OP's problem sounds like it could be yet another variation on the
theme, but this time with high CPU use. I'd suspect possibly a
misbehaving plugin since it doesn't happen to all Eclipse users.