This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: kawa.repl -C hanging on Mac OS X
On 03/08/2011 09:38 AM, Jamison Hope wrote:
On Mar 8, 2011, at 3:24 AM, Per Bothner wrote:
It appears that the need for exitIncrement/exitDecrement may have
been fixed with jdk 1.4: http://bugs.sun.com/view_bug.do?bug_id=4030718
So I'd be tempted to remove this hack. However, it appears it is
still needed on Mac OS X - due to what seems a Mac-specific AWT bug.
I wouldn't call it a bug; it's perfectly correct for a Mac
application's main method to look like this:
public static void main(String[] args) {
installDefaultMenuBar(); // used when no windows are open
}
and not have it exit immediately. It's routine for apps to outlive their
windows, especially document-based programs like text editors or web
browsers.
Java has a mechanism for this:
The Java Virtual Machine continues to execute threads until either
of the following occurs:
* The exit method of class Runtime has been called and the security
manager
has permitted the exit operation to take place.
* All threads that are not daemon threads have died, either by
returning from the call
to the run method or by throwing an exception that propagates beyond
the run method.
So in your example you need to make sure there is a non-daemon thread
running.
But I'd argue it's a bug if eawt.Application#setDefaultMenuBar creates a
non-daemon thread - it should create a daemon thread. As I understand it.
The issue here was that I wanted static code to be run at runtime, but not
at compile time.
I feel it is a bug that Kawa loads a class to to extract its definitions.
Instead, it should examine the class file, like javac does. It probably
wouldn't be very hard to fix this, since gnu.bytecode does a reasonable
job of abstracting between reflection and reading class files. When I
get the urge, I'll try it out. Or if someone feels like a project ...
BTW, now that I figured out the root of my problem, I completely commented
out the bodies of exitIncrement/Decrement in ModuleBody, and Kawa still
quits after the last window closes, so feel free to remove them (if
you're planning to officially drop support for Java 1.{1,2,3}).
Yes, I've more-or-less given on up on Java 1.{1,2,3,4}. I've suggested
that people who need Java 1.{1,2,3,4} could use something like RetroWeaver.
If people need that and run into issues (as would not surprise me), I'd
be happy to keep in conditionals for the features that RetroWeaver can't
deal with. But as long as nobody needs Kawa support for such old platforms,
I'm not going to worry about it. (It's non-trivial to test such old
jdk versions.)
init.scm's printout occurs at runtime and not compile time, for both
caller1 (require) and caller2 (import). [This is the sort of behavior
I want, so that's what I'll be using for my Mac menubar code now.]
initrun.scm's printout occurs at runtime for both, but it also occurs
at compile time for caller4 (import). [I originally had init-run +
import, which is why I was seeing my menubar code run at compile time.]
The reason is that the import needs to figure out the exported declarations
from the module. It does that using reflection, so it needs to load the
class and initialize it. And if you're specified init-run then initializing
a class runs the class bug.
As mentioned above: this is arguably a bug - instead of reflection, Kawa
should get the information it needs from the class-file.
This doesn't happen with caller3 because you've specified a source-file,
which it reads instead of loading the class file.
I don't know whether what I'm seeing here is indication of a bug, or just
a demonstration of incomplete understanding of Kawa's R6RS import.
require will behave the same as import if you leave off the source filename.
--
--Per Bothner
per@bothner.com http://per.bothner.com/