----- Original Message -----
From: "IMD" <email@hidden>
To: <email@hidden>
Sent: Wednesday, December 29, 2004 7:34 PM
Subject: crashing problem due to buckyball timer exception in
NSAppleScriptclass
> Hi,
>
> I have written a method which reads all the records from address book
> on Mac OS X.2 with the help of NSAppleScript class.
>
> Some time code is running fine but sometime it generates
> IllegalMonitorStateException. The print stack trace is given below:-
> (please see the code after print stack trace)
>
> A Buckyball Timer threw an exception:
> java.lang.IllegalMonitorStateException: current thread not owner
> at com.apple.mrj.macos.carbon.CarbonLock.release0(Native Method)
> at com.apple.mrj.macos.carbon.CarbonLock.release(CarbonLock.java:43)
> at com.apple.buckyball.app.Timer.EventLoopTimer(Timer.java:213)
> at com.apple.cocoa.foundation.NSAppleScript.execute(Native Method)
> at
> com.inmarsat.mmi.launchpad.nativeresource.macx.MacXContacts.getContactsL
> ist(MacXContacts.java:127)
>
>
A couple list members have put a certain amount of time into trying to get
AppleScript to work from java now and in past releases. Including me, so at
one point I actually disassembled and looked at some of the buckyball timer
code. This was a while ago but as I remember this was almost a normal
situation in 1.3 and earlier Carbon releases of the vm. The code seemed to
want to run and process events without holding the CarbonLock. So it would
intentionally try something that would throw this exception if it didn't
hold the lock. Since this was actually what it wanted I thought the
exception was trapped and not shown. So sort of odd you're seeing it at all
as I remember. Possibly because you're using the Cocoa and not Carbon
AppleScript API's although I can't think of a reason why that in itself
would be different in this code.
The CarbonLock was just an at odds concept with Java. The VM itself used it
especially heavily in the non-reentrant gui stuff. So it was basically cross
your fingers and hope with a gui'd applicaiton whether it would work right
doing native like AppleScript either holding or not holding the lock. Don't
hold it and your non-reentrant code might expect thread related problems.
Hold it and you risked deadlock with VM code trying to do the same.
For your best chance of success as I think has been mentioned you should run
AppleScript related from the native event thread (1.3, I haven't put as much
testing into 1.4 or later and the threading is different). Especially if you
are going to run any AppleScripts themselves involving user interaction
event related stuff like 'display dialog'.
Both the JDirect and JNIDirect versions of my macnative pacakge include some
AppleScript and NSAppleScript related. CarbonOneShot is the class I used to
run on the native event thread at 1.3. That probably makes use of a nop'd
CarbonLock interface. I finally decided the occasional rare strange
threading problem was a better risk than the rather frequent CarbonLock
deadlocks I seemed to run into.
You could probably find related threads in the archives. Steve Roy I think
also had some success with implementing AppleScript interfaces.
Runtime exec with the osascript and osacompile? commands might work better
for you and be simpler.
Mike Hall mikehall at spacestar dot net
http://www.spacestar.net/users/mikehall
_______________________________________________
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
This email sent to email@hidden
