i'm not particularly sure on this, but to my knowledge Swing object
_must not_ be created outside the AWT event thread. i would try to
never put them in static initializers. good programming practise
therefore places GUI app launchers in a EventQueue.invokeLater
command inside your main method. but as you can see from apple's
xcode java swing application template, not even they follow this
guideline of deferring jframe creation to the even thread. it's just
a guess that it might be related to this, but i'm not sure (i
remember though that i once had initialization problems related to
trying to instantiate swing object outside the event thread).
ciao, -sciss-
Am 28.08.2006 um 18:05 schrieb Jeremy Wood:
Here at work there's a guy running a release candidate of our
product on a MacBook. In the past 2 weeks, about 3 times now the
application has failed to launch. But he launches the application
about 10 times a day, so it's not a reproducible problem. He
believes it has to do with launching the application immediately
after rebooting his computer.
The errors, though, look very scary. They appear to be really high
up in Sun's code.
What I believe to be happening is that we have to make some static
calls to methods in com.t4l.io.MiscIO... in order to reach those
methods, we're initializing a static field that contains a
JFileChooser. While constructing that GUI element, a
ClassCastException is coming up... which causes all of MiscIO to
fail to load... which then makes for ClassNotFound problems
whenever we talk to MiscIO.
Below are edited console outputs; I tried to strip it down to the
stack traces and important system info. As you can see, we're
using Quaqua. I admit it wasn't the latest version; I just updated
this morning. But the ch.randelshofer calls are really low in the
stack trace; I don't think they're to blame at all. (Still,
Werner, if you have any ideas we'd love to hear them.)
It appears a KeyStroke is finding its way into a TreeMap, and a
KeyStroke is not a java.lang.Comparable... so I'm guessing that's
why the TreeMap is choking.
This is not consistently reproducible, but it's scary to have an
error this high up. We wonder if it will get worse? Besides, it
just reflects really poorly on the application when it fails to
launch. :)
Any thoughts? We found from past experience that we need to
initialize the JFileChooser early on. I forget the exact rules
(there are so many subtle tricks on Macs)... but I think if we
initialize the JFileChooser *after* QTJava, it can take over 10-20
seconds to initialize. (And if we initialize it first, it takes
less than 3.) So we'd rather figure out how to make this safe
without constructing the JFileChooser lazily.
That's a lot of background, sorry this email is so long. :) Below
are the traces. Any ideas/comments welcome.
- Jeremy Wood
P.S. Yes, he really does have two different amounts of RAM between
the two different sessions.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
