This is an issue running the program from within DrJava.
The following program:
---------------------------------------------------
import javax.swing.JButton;
import javax.swing.JFrame;
public class BrokenButton extends JFrame {
private static class MyButton extends JButton {
public MyButton() {
super("My Button");
}
}
public static void main(String[] args) {
JFrame window = new JFrame("Broken Button on Mac under
DrJava");
window.setLocation(100, 100);
window.setSize(300, 200);
window.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
window.getContentPane().add(new MyButton());
window.setVisible(true);
}
}
---------------------------------------------------
works fine on both Windows XP and Linux. On my Mac, however, it
compiles fine under DrJava but does not run correctly. What it exhibits
looks more like a label and is not clickable like a button should be. If I
compile the program under DrJava and run it from the command line
(in a Terminal window, not from DrJava), it runs fine.
The details:
Platform: Mac OS X 10.4.7 (PowerPC)
DrJava: 20060918-1737
Java:
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
Works fine on Windows XP and Linux, fails on Mac OS X
Logged In: YES
user_id=430590
This is a very mysterious error. I suspect that there is a
minor glitch in the Mac OS X JVM. DrJava loads and executes
exactly the same class files as command line execution, but
it is done in the context of a running DrJava interactions
JVM (which runs as a slave of the main JVM). This should
not have any effect on the components displayed within an
JFrame object.
We love the Mac, but its JVM (developed by Apple) has proven
less reliable in our experience than the Linux and Windows
JVMs (developed by Sun).
Logged In: YES
user_id=430590
BTW, I forgot to mention that the bug exists even when you
move the MyButton class to top level (which is not
surprising since static inner classes are compiled exactly
like top level classes except differences in the resolution
of class and field names).
Logged In: YES
user_id=1060117
Originator: NO
Fixed in the latest build. This was probably occurring due to the way class loaders restrict access to certain classes in the interactions pane. That was cleaned up recently.