[armedbear-devel] Exception Handling

[Alessio Stalla]

On Fri, Dec 18, 2009 at 12:28 AM, Mark Evenson <evenson at 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