#261 Interactions importing & execution flakiness
Under OS X 10.3.3 with Jave version 1.4.2_03 and Java
VM 1.4.2-34, DrJava (stable release of 2004/03/26) is
doing these things in the Interactions pane:
1. If all classes of javax.swing or of java.awt are
imported, DrJava resumes OK from the import command,
but, if only one class is imported, specifically
JColorChooser or Color, then DrJava goes into the
background and edu.rice.cs.util.newjvm.SlaveJVMRunner
comes into the foreground and stays there, until the
user manually brings DrJava back into the foreground;
until then any typing in the Interactions pane is
impossible.
2. Each invocation of JColorChooser.showDialog results
in edu.rice.cs.util.newjvm.SlaveJVMRunner remaining in
the foreground, as above.
3. The first invocation of JColorChooser.showDialog may
display the color dialog window in front, but all
subsequent invocations bring it to the front only for a
split second, after which it recedes into the
background until the user manually brings it into the
foreground to use it.
4. Erratically, some invocations of
JColorChooser.showDialog also yield null, rather than a
Color.
Logged In: YES
user_id=431096
The appearance of the SlaveJVMRunner icon in the Dock is an artifact of
the way Mac OS X deals with Java processes. If the JVM loads certain
classes from the AWT or Swing packages, the system assumes that you
are working with a graphical application and presents a Dock icon. When
it does so, it gives the keyboard focus to the JVM, as if you were
launching a new application. This is the source of #1 above, and
unfortunately there is little we can do to prevent this behavior. We use
an independent JVM for the interactions pane so that it can be reset
without disrupting the JVM in which the main editing session executes.
Similar issues are behind #2 and #3. In the Mac OS X implementation
of Swing, activating windows may or may not bring them to the front and
may or may not change the keyboard focus. (IMHO, this is a broken
behavior, and it's certainly very frustrating for us.) As far as I know,
only Apple is able to change this behavior, as well.
#4 sounds like either yet another bug in Apple's Swing implementation
(we've discovered several) or a quirk in the color chooser API. You may
want to check Apple's Java developer website to see if it is a known
issue. From your description, it seems unlikely to be unique to DrJava.
Does this also occur in classes you compile from the Definitions pane?
Logged In: YES
user_id=1019197
"Does this also occur in classes you compile from the
Definitions
pane?"
Yes, it does. About every 3rd or 4th invocation returns a
null value.