AWT : Automatic call to System.exit(0)
rodsenra at correionet.com.br
Thu Jun 17 20:53:02 PDT 1999
For the record the bug I reported was previously reported
by Patrick Tullmann on message Id #129. That scaped me
from my pre-reporting search at the bug database (but
that's a long story of clumsiness that I won't tell
for my vain's sake)
> On Jun 17, 1999, Peter Mehlitz <peter at transvirtual.com> wrote:
>Yes, it's from the "it's a feature, not a bug" section. But I don't know if I
>really want to change the default (I've seen so many apps simply not
>terminating under JDK at all).
All right. But isn't Kaffe's goal to behave like other JVM behave
specially Sun JVM
(should I call it standard JVM?) behave ? So, in order to prevent apps
NOT terminating couldn't we introduce a different mechanisms instead of
the JVM ? Woulnd't you agree that killing remaining non-AWT threads
after the last
AWT passes way is to strong and more prone to let the programmer
I mean: What's more frustraiting a non-terminating empty program or an
program ? These are my best attempts to convince Mehlitz to change the
I have followed a suggestion from Patrick and simply removed
System.exit(0) from AWTEvent.java.
Remaining threads survive, it works but there are side effects.
Depending on timing,
the EventDispatching thread might raise a NullPointerException before
it's blocked from
Toolkit.stopDispatch(). There are some ways to circumvent this but it
all depends on
agreement regarding to invert default behaviour. I am insisting on this
subject because I'm
deeply convinced that today's configuration will prove too restricting
in the future for
any "partial-time graphical" applications.
RodSenra> I dug a little and found out at class Default a static field
Mehlitz > Right, that's how it is controlled.
When I need to deploy my apps on a foreign Kafee JVM should I then
always replace its
class Default ? Instead why it cannot be manipulated publicly through
fields or methods ?
The point is : if there are means to change the behavior shouldn't they
be as simple as possible ?
In this case I have another supporter...
Alexandre Oliva wrote:
> I'd rather have the `standard' behavior, in this case. You can always
> ^C if it doesn't terminate, but you can't get it to proceed from where
> it stopped if it just exit()s :-(
> I'd vote for having this defined in a property file, or as a
> command-line property (say, -Dkaffe.awt.AutoExit=true)
Oliva has got my vote too.
More information about the kaffe