AWT : Automatic call to System.exit(0)

[Rodrigo Senra]

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
from
NOT terminating couldn't we introduce a different mechanisms instead of
shutting down
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
unsatisfied ?
I mean: What's more frustraiting a non-terminating empty program or an
abended active
program ? These are my best attempts to convince Mehlitz to change the
default. 

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
AutoStop
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.

best regards,
Rod Senra