Ladies and Gentlemen,
I'm writing to ask how to handle exceptions generated in Java code called from ABCL.
I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp.
One problem we're facing is how to handle gracefully exceptions generated in Lisp code called from Java. In our case, we'll need to make calls back to the Java front-end to get user information and to display results. Some of these calls throw exceptions. What is the best way to catch these?
I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls.
Thanks!
Peter Olsen
On Thu, Dec 17, 2009 at 8:50 PM, Peter Olsen pcolsen@gmail.com wrote:
Ladies and Gentlemen,
I'm writing to ask how to handle exceptions generated in Java code called from ABCL.
I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp.
One problem we're facing is how to handle gracefully exceptions generated in Lisp code called from Java. In our case, we'll need to make calls back to the Java front-end to get user information and to display results. Some of these calls throw exceptions. What is the best way to catch these?
I'm not sure I've understood what you want. If you need to handle in Lisp exceptions thrown by Java code, using the standard Common Lisp condition facilities, you can use the primitive (register-java-exception class-name condition-class), where class-name is a string naming a Java exception class and condition-class is a symbol naming a Lisp condition, which must be a subclass of java-exception. Every time a Java call is made that throws a registered exception, the corresponding Lisp condition is signaled. IIRC if you don't register any exception that way, all exceptions are remapped to a generic condition of type java-exception. If instead you want to handle in Java conditions signaled by Lisp code, you can use the debugger hook to replace ABCL's debugger with a function that throws a Java exception. ABCL includes such a function (afaik it was used in the J editor): sys::%debugger-hook-function. Of course you won't be able to use CL restarts from Java with exceptions thrown by this debugger hook, since throwing a Java exception always unwinds the stack.
I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls.
I have never used JSS, and didn't even know it existed. I'm aware of an invoke.lisp with supposedly similar functionality but with the drawback of requiring an additional Java library. I also wrote my little, less powerful Java easy access layer for a project of mine, and I can say that having nicer syntax for Java calls improves code readability quite a lot. On the other hand, if you need the maximum efficiency (i.e. no more runtime dispatch than what Java itself does, plus the necessary reflection overhead), ABCL's native calls are the best choice.
hth, Alessio
On 12/17/09 5:49 PM, Alessio Stalla wrote: […]
I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls.
I have never used JSS, and didn't even know it existed. I'm aware of an invoke.lisp with supposedly similar functionality but with the drawback of requiring an additional Java library. I also wrote my little, less powerful Java easy access layer for a project of mine, and I can say that having nicer syntax for Java calls improves code readability quite a lot. On the other hand, if you need the maximum efficiency (i.e. no more runtime dispatch than what Java itself does, plus the necessary reflection overhead), ABCL's native calls are the best choice.
'invoke.lisp' is the name of the main part of the JSS implementation, so they are different ways of saying the same thing.
JSS actually requires two additional JAR files to work, but both are actually checked into the JSS SVN repository, so there are dependable URIs that resolve to the necessary bytes which only need to be downloaded once per system you wish to deploy upon. The 'additional.jars' property of the Ant based build system can be used to more or less automatically include references to them on a local filesystem while following the ABCL SVN trunk, so once you have the JARs locally on a machine, have set the proper paths in 'build.properties', and referenced JSS via the 'jss.asd' file in the ASDF repo, things are pretty easy.
For my personal taste, the best thing about JSS is how the #" macro makes using Java more like Lisp by placing the method first in the s-expr so I find that using
(#"toString" (new 'Foo))
rather than (let ((foo (jnew (jconstructor "some.long.package.name.Foo")))) (jcall (jmethod "toString" "some.long.package.name.Foo") foo))
just makes things a lot easier to parse mentally, especially once your code gets rather long.
There are some corner cases where using JSS gets a bit peculiar (like accessing Java Enums if I remember correctly), but overall I would definitely endorse it.
Alessio is completely correct that there is a fair amount of overhead in supporting JSS's #" macro as it dynamically searches the Java namespace for method resolution, but I never really ran into problems with that.
I also wrote most of the code I used JSS for before Alessio's layer existed, so my preference for JSS did not result from any comparison between the two.
However you choose to use ABCL, please let us know how things are going once you get some experiences to report.
On Fri, Dec 18, 2009 at 12:28 AM, Mark Evenson evenson@panix.com wrote:
On 12/17/09 5:49 PM, Alessio Stalla wrote: […]
I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls.
I have never used JSS, and didn't even know it existed. I'm aware of an invoke.lisp with supposedly similar functionality but with the drawback of requiring an additional Java library. I also wrote my little, less powerful Java easy access layer for a project of mine, and I can say that having nicer syntax for Java calls improves code readability quite a lot. On the other hand, if you need the maximum efficiency (i.e. no more runtime dispatch than what Java itself does, plus the necessary reflection overhead), ABCL's native calls are the best choice.
'invoke.lisp' is the name of the main part of the JSS implementation, so they are different ways of saying the same thing.
Oh ok, I didn't know that.
JSS actually requires two additional JAR files to work, but both are actually checked into the JSS SVN repository, so there are dependable URIs that resolve to the necessary bytes which only need to be downloaded once per system you wish to deploy upon. The 'additional.jars' property of the Ant based build system can be used to more or less automatically include references to them on a local filesystem while following the ABCL SVN trunk, so once you have the JARs locally on a machine, have set the proper paths in 'build.properties', and referenced JSS via the 'jss.asd' file in the ASDF repo, things are pretty easy.
For my personal taste, the best thing about JSS is how the #" macro makes using Java more like Lisp by placing the method first in the s-expr so I find that using
(#"toString" (new 'Foo))
rather than
(let ((foo (jnew (jconstructor "some.long.package.name.Foo")))) (jcall (jmethod "toString" "some.long.package.name.Foo") foo))
just makes things a lot easier to parse mentally, especially once your code gets rather long.
Absolutely! It's much nicer that way.
There are some corner cases where using JSS gets a bit peculiar (like accessing Java Enums if I remember correctly), but overall I would definitely endorse it.
Alessio is completely correct that there is a fair amount of overhead in supporting JSS's #" macro as it dynamically searches the Java namespace for method resolution, but I never really ran into problems with that.
Yes, I don't expect the overhead to be problematic in general, and anyway if it turns out to be you can selectively replace the problematic calls with abcl's native operators, while using the much more convenient syntax for everything else.
I also wrote most of the code I used JSS for before Alessio's layer existed, so my preference for JSS did not result from any comparison between the two.
JSS wins the comparison a priori: my 'layer' is just a bunch of functions for invoking Java which I believed to be useful in my specific project. It's not meant to be a stand-alone, comprehensive library like JSS; I only cited it to prove that I have direct experience in using an easier Java access layer.
Bye, Alessio
Hi Peter,
On Thu, Dec 17, 2009 at 8:50 PM, Peter Olsen pcolsen@gmail.com wrote:
Ladies and Gentlemen,
I'm writing to ask how to handle exceptions generated in Java code called from ABCL.
I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp.
That's great news!
Others have explained how this all works. Let me stress however that if you want more information, please ask! We're here not only to develop ABCL, but also to listen to users who want to use it (but may have trouble doing so).
We want to be known as a cooperative group with a prompt responses. If you need more interactive responses, you could try logging into the #abcl irc channel on freenode. Or you could try reaching me through Google Chat.
With kind regards,
Erik.
Do drop me a line if you have any trouble with JSS. Or have ideas for extensions.
Best, Alan
On 12/18/09, Erik Huelsmann ehuels@gmail.com wrote:
Hi Peter,
On Thu, Dec 17, 2009 at 8:50 PM, Peter Olsen pcolsen@gmail.com wrote:
Ladies and Gentlemen,
I'm writing to ask how to handle exceptions generated in Java code called from ABCL.
I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp.
That's great news!
Others have explained how this all works. Let me stress however that if you want more information, please ask! We're here not only to develop ABCL, but also to listen to users who want to use it (but may have trouble doing so).
We want to be known as a cooperative group with a prompt responses. If you need more interactive responses, you could try logging into the #abcl irc channel on freenode. Or you could try reaching me through Google Chat.
With kind regards,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Erik Huelsmann -
Mark Evenson -
Peter Olsen