ArmedBear / J

On Tue, 25 Oct 2005, Peter Graves wrote:

> Hi Andras,
>
> What is the status of REGISTER-JAVA-EXCEPTION?

The short answer is that it's a reminder that something like it would be nice...

The longer is buried in these messages:
http://sourceforge.net/mailarchive/message.php?msg_id=10626371
http://sourceforge.net/mailarchive/message.php?msg_id=10626999
http://sourceforge.net/mailarchive/message.php?msg_id=10628238

I can't recall what problems I ran into later. They may have had
something to do with PRINT-OBJECT not doing what it was meant to, and
this causing problems with popping up restarts in the slime debugger.

>
> I can't find any calls to it in src/org/armedbear/lisp/*.lisp.

That in itself wouldn't necessarily be a problem. The only place in
ABCL's sources where this could be useful is probably java.lisp.

>
> The idea seems reasonable, but the implementation doesn't seem very
> robust (for example, there's no code to ensure that the symbol argument
> actually names a condition), so it looks a bit experimental.

It certainly is.

>
> The larger problem is that global mappings don't give you granularity,
> so you can't map a particular exception class to condition A for call A
> and to condition B for call B, for example.

That's true, but isn't it the _handling_ of the condition that should
vary from call to call? My - perhaps too simplistic - idea was that
there would be a DEF-JAVA-EXCEPTION macro analogous to (an imaginary,
or jfli's) DEF-JAVA-CLASS, so one can more less automatically work
with conditions instead of having to deal with Java exceptions.

>
> We probably do need to report exceptions thrown by Java code invoked by
> JCALL and friends, but I think it might make more sense to define some
> sort of JAVA-CONDITION that would just encapsulate the thrown Java
> exception. Then user code could simply HANDLER-BIND or HANDLER-CASE
> JAVA-CONDITION and dispatch on the encapsulated exception.

It's not clear to me how one could dispatch on the Java exception.
And isn't the whole point of all this is to not to have to worry about
exceptions, but only conditions? But I may very well be missing
something!

Andras

On Wed, 26 Oct 2005 at 00:11:18 +0200, Andras Simon wrote:
> > The larger problem is that global mappings don't give you granularity,
> > so you can't map a particular exception class to condition A for call A
> > and to condition B for call B, for example.
>
> That's true, but isn't it the _handling_ of the condition that should
> vary from call to call? My - perhaps too simplistic - idea was that
> there would be a DEF-JAVA-EXCEPTION macro analogous to (an imaginary,
> or jfli's) DEF-JAVA-CLASS, so one can more less automatically work
> with conditions instead of having to deal with Java exceptions.

I misunderstood what was going on.

In the first of the three messages you referenced (a conversation I had
totally forgotten until you reminded me) you gave a nice example of how
this mechanism is supposed to work:

    (define-condition illegal-argument (error) ())

    (register-java-exception "java.lang.IllegalArgumentException" 'illegal-argument)

    (jstatic (jmethod "java.lang.String" "valueOf" "int") "java.lang.String" 23.1)
    Debugger invoked on condition of type ILLEGAL-ARGUMENT:
       #
    Restarts:
       0: ABORT Abort handling SLIME request.

So far so good.

I think the idea of a DEF-JAVA-EXCEPTION macro is a good one, too. So
instead of:

    (define-condition illegal-argument (error) ())
    (register-java-exception "java.lang.IllegalArgumentException" 'illegal-argument)

you could just do:

    (def-java-exception illegal-argument "java.lang.IllegalArgumentException")

Or maybe even just

    (def-java-exception "java.lang.IllegalArgumentException")

and some sort of magic would happen that would define a condition
called java.lang.illegal-argument-exception.

OK.

In the last of the three referenced messages, you suggested:

    And now I think that adding a few slots to conditions that are
    signaled when Java exceptions are raised would be a good thing. To
    keep entropy at bay, a condition JAVA-EXCEPTION could be defined
    with just two slots: MESSAGE and STACK-TRACE. It would report the
    MESSAGE only. Users could subclass this condition, and expect the
    two slots to be filled in when it is signaled.

So DEF-JAVA-EXCEPTION would define a condition that would be a subclass
of JAVA-EXCEPTION (rather than ERROR, as in the examble above).

OK.

(But I think we might only need one slot, which would be filled in with
a JAVA-OBJECT that wrapped the original Java Throwable object. That way
we'd never lose any of the information from the original Throwable, if
by some chance it contained more than MESSAGE and STACK-TRACE.)

> > We probably do need to report exceptions thrown by Java code invoked by
> > JCALL and friends, but I think it might make more sense to define some
> > sort of JAVA-CONDITION that would just encapsulate the thrown Java
> > exception. Then user code could simply HANDLER-BIND or HANDLER-CASE
> > JAVA-CONDITION and dispatch on the encapsulated exception.
>
> It's not clear to me how one could dispatch on the Java exception.

I was thinking of JAVA-CONDITION as being roughly equivalent to your
JAVA-EXCEPTION, except with just one slot for the original Java
Throwable.

Then the user could dispatch on the contents of that slot by hand in
the HANDLER-CASE clause:

    (handler-case
        (jcall x y)
      (java-exception (c)
        (let* ((throwable (java-exception-throwable c))
               (class-name (jclass-of throwable)))
          (cond ((equal class-name "java.lang.ClassCastException")
                 (do-something))
                ((equal class-name "java.lang.NullPointerException")
                 (do-something-else))))))

Which, admittedly, is pretty awkward compared to:

    (handler-case
        (jcall x y)
      (java.lang.class-cast-exception (c) (do-something))
      (java.lang.null-pointer-exception (c) (do-something-else))

> And isn't the whole point of all this is to not to have to worry about
> exceptions, but only conditions? But I may very well be missing
> something!

No, I think you're absolutely right.

But I still have a question (maybe more than one, but one for now).

Consider an application that uses multiple third-party library modules.
One module might do

    (define-condition null-pointer-error (java-exception) ())
    (register-java-exception "java.lang.IllegalArgumentException"
                             'null-pointer-error)

and another module might do

    (define-condition null-pointer-exception (java-exception) ())
    (register-java-exception "java.lang.IllegalArgumentException"
                             'null-pointer-exception)    

It seems like whichever of these modules is loaded last will get its
way with the handling of NullPointerExceptions, and the other one won't
see them at all. This is what I was getting at when I complained that
global mappings don't give you granularity.

What should we do about this?

-Peter

On Wed, 26 Oct 2005 at 07:40:15 -0700, Peter Graves wrote:
> One module might do
>
>     (define-condition null-pointer-error (java-exception) ())
>     (register-java-exception "java.lang.IllegalArgumentException"
>                              'null-pointer-error)
>
> and another module might do
>
>     (define-condition null-pointer-exception (java-exception) ())
>     (register-java-exception "java.lang.IllegalArgumentException"
>                              'null-pointer-exception)    
>
> It seems like whichever of these modules is loaded last will get its
> way with the handling of NullPointerExceptions, and the other one won't
> see them at all. This is what I was getting at when I complained that
> global mappings don't give you granularity.
>
> What should we do about this?

My example contains a cut-and-paste error that muddies the waters.
It should have been:

    One module might do

        (define-condition null-pointer-error (java-exception) ())
        (register-java-exception "java.lang.NullPointerException"
                                            ^^^^^^^^^^^^^^^^^^^^
                                 'null-pointer-error)

    and another module might do

        (define-condition null-pointer-exception (java-exception) ())
        (register-java-exception "java.lang.NullPointerException"
                                            ^^^^^^^^^^^^^^^^^^^^
                                 'null-pointer-exception)

-Peter

On Wed, 26 Oct 2005, Peter Graves wrote:

> On Wed, 26 Oct 2005 at 00:11:18 +0200, Andras Simon wrote:
>>> The larger problem is that global mappings don't give you granularity,
>>> so you can't map a particular exception class to condition A for call A
>>> and to condition B for call B, for example.
>>
>> That's true, but isn't it the _handling_ of the condition that should
>> vary from call to call? My - perhaps too simplistic - idea was that
>> there would be a DEF-JAVA-EXCEPTION macro analogous to (an imaginary,
>> or jfli's) DEF-JAVA-CLASS, so one can more less automatically work
>> with conditions instead of having to deal with Java exceptions.
>
> I misunderstood what was going on.
>
> In the first of the three messages you referenced (a conversation I had
> totally forgotten until you reminded me) you gave a nice example of how
> this mechanism is supposed to work:
>
>    (define-condition illegal-argument (error) ())
>
>    (register-java-exception "java.lang.IllegalArgumentException" 'illegal-argument)
>
>    (jstatic (jmethod "java.lang.String" "valueOf" "int") "java.lang.String" 23.1)
>    Debugger invoked on condition of type ILLEGAL-ARGUMENT:
>       #
>    Restarts:
>       0: ABORT Abort handling SLIME request.
>

Somewhat surprisingly (since this part of ABCL hasn't been touched for
a long time, and probably noone's using it), it's not only how it's
supposed to work, it's how it actually works!

> So far so good.
>
> I think the idea of a DEF-JAVA-EXCEPTION macro is a good one, too. So
> instead of:
>
>    (define-condition illegal-argument (error) ())
>    (register-java-exception "java.lang.IllegalArgumentException" 'illegal-argument)
>
> you could just do:
>
>    (def-java-exception illegal-argument "java.lang.IllegalArgumentException")
>
> Or maybe even just
>
>    (def-java-exception "java.lang.IllegalArgumentException")
>
> and some sort of magic would happen that would define a condition
> called java.lang.illegal-argument-exception.
>
> OK.

Yes, register-java-exception was meant to be the low-level mechanism
on top of which a fancy def-java-exception macro could be built
eventually. Just as jcall and friends are the foundation for jfli.

>
> In the last of the three referenced messages, you suggested:
>
>    And now I think that adding a few slots to conditions that are
>    signaled when Java exceptions are raised would be a good thing. To
>    keep entropy at bay, a condition JAVA-EXCEPTION could be defined
>    with just two slots: MESSAGE and STACK-TRACE. It would report the
>    MESSAGE only. Users could subclass this condition, and expect the
>    two slots to be filled in when it is signaled.
>
> So DEF-JAVA-EXCEPTION would define a condition that would be a subclass
> of JAVA-EXCEPTION (rather than ERROR, as in the examble above).

I even have a JavaException (a subclass of LispError) lying around;
but I can't recall what its purpose in life was, or why I abandoned
it. I must've run into something because it looks very, hmmm, sparse.

>
> OK.
>
> (But I think we might only need one slot, which would be filled in with
> a JAVA-OBJECT that wrapped the original Java Throwable object. That way
> we'd never lose any of the information from the original Throwable, if
> by some chance it contained more than MESSAGE and STACK-TRACE.)

I originally wanted to have slots in the condition corresponding to
all (or at least a big subset of) the methods of the Java exception,
that would be filled in by invoking those methods. But then I thought
(or you suggested) that that was an overkill (and would probably be
too slow anyway). So, as a compromise, I opted for just two slots: the
message and the stack trace. (That's where the allusion to entropy
comes from.) But message + the throwable itself is probably a better
compromise.

>
>>> We probably do need to report exceptions thrown by Java code invoked by
>>> JCALL and friends, but I think it might make more sense to define some
>>> sort of JAVA-CONDITION that would just encapsulate the thrown Java
>>> exception. Then user code could simply HANDLER-BIND or HANDLER-CASE
>>> JAVA-CONDITION and dispatch on the encapsulated exception.
>>
>> It's not clear to me how one could dispatch on the Java exception.
>
> I was thinking of JAVA-CONDITION as being roughly equivalent to your
> JAVA-EXCEPTION, except with just one slot for the original Java
> Throwable.
>
> Then the user could dispatch on the contents of that slot by hand in
> the HANDLER-CASE clause:
>
>    (handler-case
>        (jcall x y)
>      (java-exception (c)
>        (let* ((throwable (java-exception-throwable c))
>               (class-name (jclass-of throwable)))
>          (cond ((equal class-name "java.lang.ClassCastException")
>                 (do-something))
>                ((equal class-name "java.lang.NullPointerException")
>                 (do-something-else))))))
>
> Which, admittedly, is pretty awkward compared to:

Not only that, but it's also very much against the spirit of the CL
condition system. (Or that is how it looks to me; I'm no condition
system guru: far from it!)

>
>    (handler-case
>        (jcall x y)
>      (java.lang.class-cast-exception (c) (do-something))
>      (java.lang.null-pointer-exception (c) (do-something-else))

I think that this is the good direction.

>
>> And isn't the whole point of all this is to not to have to worry about
>> exceptions, but only conditions? But I may very well be missing
>> something!
>
> No, I think you're absolutely right.
>
> But I still have a question (maybe more than one, but one for now).
>
> Consider an application that uses multiple third-party library modules.
> One module might do
>
>    (define-condition null-pointer-error (java-exception) ())
>    (register-java-exception "java.lang.IllegalArgumentException"
>                             'null-pointer-error)
>
> and another module might do
>
>    (define-condition null-pointer-exception (java-exception) ())
>    (register-java-exception "java.lang.IllegalArgumentException"
>                             'null-pointer-exception)
>
> It seems like whichever of these modules is loaded last will get its
> way with the handling of NullPointerExceptions, and the other one won't
> see them at all. This is what I was getting at when I complained that
> global mappings don't give you granularity.
>
> What should we do about this?

Perhaps we could avoid it by having

(def-java-exception "java.lang.IllegalArgumentException")

as opposed to

(def-java-exception illegal-argument "java.lang.IllegalArgumentException")

i.e. by not letting the user mess with exceptions too much. This seems
like a relatively clean if not very flexible approach.

Or we could signal a continuable error in case of a redefinition (or
should I say re-registration?) attempt. (I like this the best.)

There could also be a rebinding mechanism (as with dynamic variables)
but that somehow feels wrong (and an overkill) to me. Not that I see
clearly what this would involve.

The longer I look at it, the more I like the second option.
Especially, for a 0.1 release. We just don't have enough experience to
know if it'll hurt anyone, so why draw up elaborate plans to avoid the
pain that may never come. And option no. 2 also leaves room for some
experimentation.

Motto: People should be creative in how they deal with errors, not how
they name it.

What do you think?

Andras

On Wed, 26 Oct 2005 at 18:47:48 +0200, Andras Simon wrote:
> On Wed, 26 Oct 2005, Peter Graves wrote:
> >
> > Consider an application that uses multiple third-party library modules.
> > One module might do
> >
> >    (define-condition null-pointer-error (java-exception) ())
> >    (register-java-exception "java.lang.IllegalArgumentException"
> >                             'null-pointer-error)
> >
> > and another module might do
> >
> >    (define-condition null-pointer-exception (java-exception) ())
> >    (register-java-exception "java.lang.IllegalArgumentException"
> >                             'null-pointer-exception)
> >
> > It seems like whichever of these modules is loaded last will get its
> > way with the handling of NullPointerExceptions, and the other one won't
> > see them at all. This is what I was getting at when I complained that
> > global mappings don't give you granularity.
> >
> > What should we do about this?
>
> Perhaps we could avoid it by having
>
> (def-java-exception "java.lang.IllegalArgumentException")
>
> as opposed to
>
> (def-java-exception illegal-argument "java.lang.IllegalArgumentException")
>
> i.e. by not letting the user mess with exceptions too much. This seems
> like a relatively clean if not very flexible approach.

Yeah, this is essentially the jFli approach, applied to the subject of
exceptions.

I think this approach is fine, but it's a higher level approach, and
should be part of the higher level API, which is not really what we're
talking about here.

> Or we could signal a continuable error in case of a redefinition (or
> should I say re-registration?) attempt. (I like this the best.)

OK.

> There could also be a rebinding mechanism (as with dynamic variables)
> but that somehow feels wrong (and an overkill) to me. Not that I see
> clearly what this would involve.

I don't really see what this would involve either, and it does seem
like overkill, so let's not go down that road.

> The longer I look at it, the more I like the second option.

I think that's a fine plan (the second option being a continuable error
in case of a re-registration attempt, just to be perfectly clear).

> Especially, for a 0.1 release. We just don't have enough experience to
> know if it'll hurt anyone, so why draw up elaborate plans to avoid the
> pain that may never come. And option no. 2 also leaves room for some
> experimentation.
>
> Motto: People should be creative in how they deal with errors, not how
> they name it.
>
> What do you think?

I think there's at least one further issue.

Suppose (for the sake of argument) you do:

    (define-condition throwable (java-exception) ())
    (register-java-exception "java.lang.Throwable" 'throwable)

And then some call to Java throws a NullPointerException (for example).

Now, you haven't registered "java.lang.NullPointerException". But from
Java's point of view, a NullPointerException _is_ a Throwable, so the
condition registered for "java.lang.Throwable" should arguably be
signalled.

You can't accomplish this with a simple hashtable lookup of
"java.lang.NullPointerException". You'd have to walk the list of
registered exceptions and check to see if the class of the exception at
hand is either identical to, or a subclass of, one of the registered
exception classes. And the order in which you walked the list would
matter, in exactly the same way the order of catch clauses matters
after a try block in Java code.

Having mentioned this issue, I don't plan to do anything about it right
now.

For the moment, I think I'm going to leave the registration mechanism
as it is, except that I do plan to introduce a JavaException class,
more or less as we've discussed it, and make sure that when no
exceptions are registered, Java exceptions are caught and a well-formed
JavaException (or JAVA-EXCEPTION) is signalled on the Lisp side, with a
plausible error message.

This should be reasonably safe, while leaving plenty of room for
experimentation while we acquire the experience that will enable us to
do a better job somewhere down the road, when we have real users
complaining about real problems.

Thanks for your help with this!

-Peter

On Thu, 27 Oct 2005 at 05:27:45 -0700, Peter Graves wrote:
> For the moment, I think I'm going to leave the registration mechanism
> as it is, except that I do plan to introduce a JavaException class,
> more or less as we've discussed it, and make sure that when no
> exceptions are registered, Java exceptions are caught and a well-formed
> JavaException (or JAVA-EXCEPTION) is signalled on the Lisp side, with a
> plausible error message.

Done.

For example:

    CL-USER(1): (jnew (jconstructor "java.lang.String" "java.lang.String")
                      (make-immediate-object nil :ref))
    Debugger invoked on condition of type JAVA-EXCEPTION:
      java.lang.reflect.InvocationTargetException
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
            at org.armedbear.lisp.Java$9.execute(Java.java:376)
            at org.armedbear.lisp.Primitive.execute(Primitive.java:102)
            at org.armedbear.lisp.LispThread.execute(LispThread.java:621)
            at org.armedbear.lisp.Lisp.evalCall(Lisp.java:424)
            at org.armedbear.lisp.Lisp.eval(Lisp.java:391)
            at org.armedbear.lisp.Primitives$16.execute(Primitives.java:268)
            at org.armedbear.lisp.LispThread.execute(LispThread.java:603)
            at org.armedbear.lisp.Lisp.evalCall(Lisp.java:418)
            at org.armedbear.lisp.Lisp.eval(Lisp.java:391)
            at org.armedbear.lisp.Primitives$136.execute(Primitives.java:3378)
            at org.armedbear.lisp.Lisp.eval(Lisp.java:380)
            at org.armedbear.lisp.Closure.execute(Closure.java:388)
            at org.armedbear.lisp.LispThread.execute(LispThread.java:603)
            at org.armedbear.lisp.Lisp$1.execute(Lisp.java:250)
            at org.armedbear.lisp.Symbol.execute(Symbol.java:666)
            at org.armedbear.lisp.LispThread.execute(LispThread.java:603)
            at org.armedbear.lisp.top_level_44.execute(top-level.lisp:390)
            at org.armedbear.lisp.CompiledFunction.execute(CompiledFunction.java:51)
            at org.armedbear.lisp.Symbol.execute(Symbol.java:656)
            at org.armedbear.lisp.LispThread.execute(LispThread.java:586)
            at org.armedbear.lisp.top_level_45.execute(top-level.lisp:399)
            at org.armedbear.lisp.LispThread.execute(LispThread.java:586)
            at org.armedbear.lisp.Interpreter.run(Interpreter.java:361)
            at org.armedbear.lisp.Main.main(Main.java:32)
    Caused by: java.lang.NullPointerException
            at java.lang.String.<init>(String.java:141)
            ... 28 more
    Restarts:
      0: TOP-LEVEL Return to top level.
    [1] CL-USER(2): (describe *debug-condition*)
    #<JAVA-EXCEPTION {E38FAE}> is an object of type JAVA-EXCEPTION.
    [1] CL-USER(3): (inspect *debug-condition*)
       0 LAYOUT -----------> #<SYSTEM:LAYOUT {1EDC290}>
       1 FORMAT-CONTROL ---> NIL
       2 FORMAT-ARGUMENTS -> NIL
       3 CAUSE ------------> #<JAVA-OBJECT java.lang.reflect.InvocationTargetException {80B973}>
    [2i] CL-USER(4): :reset
    CL-USER(5): 

Thanks for your support.

-Peter

[Sorry for the late reply; my adsl modem gave up the ghost after a
power outage, and it took two days to get a replacement.]

On Thu, 27 Oct 2005, Peter Graves wrote:

> Suppose (for the sake of argument) you do:
>
>    (define-condition throwable (java-exception) ())
>    (register-java-exception "java.lang.Throwable" 'throwable)
>
> And then some call to Java throws a NullPointerException (for example).
>
> Now, you haven't registered "java.lang.NullPointerException". But from
> Java's point of view, a NullPointerException _is_ a Throwable, so the
> condition registered for "java.lang.Throwable" should arguably be
> signalled.
>
> You can't accomplish this with a simple hashtable lookup of
> "java.lang.NullPointerException". You'd have to walk the list of
> registered exceptions and check to see if the class of the exception at
> hand is either identical to, or a subclass of, one of the registered
> exception classes. And the order in which you walked the list would
> matter, in exactly the same way the order of catch clauses matters
> after a try block in Java code.

How about walking the list of superclasses of the exception thrown
(starting with itself of course), and stop at the first that is
registered?

Andras

On Fri, 28 Oct 2005, Peter Graves wrote:

> On Thu, 27 Oct 2005 at 05:27:45 -0700, Peter Graves wrote:
>> For the moment, I think I'm going to leave the registration mechanism
>> as it is, except that I do plan to introduce a JavaException class,
>> more or less as we've discussed it, and make sure that when no
>> exceptions are registered, Java exceptions are caught and a well-formed
>> JavaException (or JAVA-EXCEPTION) is signalled on the Lisp side, with a
>> plausible error message.
>
> Done.
>
> For example:
>
>    CL-USER(1): (jnew (jconstructor "java.lang.String" "java.lang.String")
>                      (make-immediate-object nil :ref))
>    Debugger invoked on condition of type JAVA-EXCEPTION:
>      java.lang.reflect.InvocationTargetException

Since this exception is an artifact of our using reflection behind the
scenes, I think it would make sense to get the real cause (by
getCause()) and present that to the user (and also to check that on
the registered exceptions list). Then we'd have

CL-USER(5): (jnew (jconstructor "java.lang.String" "java.lang.String")
                       (make-immediate-object nil :ref)) 
Debugger invoked on condition of type JAVA-EXCEPTION:
   java.lang.NullPointerException
         at java.lang.String.<init>(String.java:144) 
...

[1] CL-USER(7): (inspect *debug-condition*)
    0 LAYOUT -----------> #<SYSTEM:LAYOUT {176ED77}>
    1 FORMAT-CONTROL ---> NIL
    2 FORMAT-ARGUMENTS -> NIL
    3 CAUSE ------------> #<JAVA-OBJECT java.lang.NullPointerException {E02FC4}>

and

CL-USER(9): (jnew (jconstructor "java.lang.String" "java.lang.String") 23) 
Debugger invoked on condition of type JAVA-EXCEPTION:
   java.lang.IllegalArgumentException: argument type mismatch

[1] CL-USER(10): (inspect *debug-condition*)
    0 LAYOUT -----------> #<SYSTEM:LAYOUT {176ED77}>
    1 FORMAT-CONTROL ---> NIL
    2 FORMAT-ARGUMENTS -> NIL
    3 CAUSE ------------> #<JAVA-OBJECT java.lang.IllegalArgumentException {600A08}>

Perhaps a good rule of thumb is that exceptions that are in the
java.lang.reflect package should be replaced with their causes, and
all other exceptions should be left alone.

One possible problem with this is if the user is doing her own
reflection.

Andras

On Sat, 29 Oct 2005, Andras Simon wrote:

> On Thu, 27 Oct 2005, Peter Graves wrote:
>
>> Suppose (for the sake of argument) you do:
>> 
>>    (define-condition throwable (java-exception) ())
>>    (register-java-exception "java.lang.Throwable" 'throwable)
>> 
>> And then some call to Java throws a NullPointerException (for example).
>> 
>> Now, you haven't registered "java.lang.NullPointerException". But from
>> Java's point of view, a NullPointerException _is_ a Throwable, so the
>> condition registered for "java.lang.Throwable" should arguably be
>> signalled.
>> 
>> You can't accomplish this with a simple hashtable lookup of
>> "java.lang.NullPointerException". You'd have to walk the list of
>> registered exceptions and check to see if the class of the exception at
>> hand is either identical to, or a subclass of, one of the registered
>> exception classes. And the order in which you walked the list would
>> matter, in exactly the same way the order of catch clauses matters
>> after a try block in Java code.
>
> How about walking the list of superclasses of the exception thrown
> (starting with itself of course), and stop at the first that is
> registered?

I committed some changes (for JNEW only) in this spirit, so now we
have

CL-USER> (define-condition throwable (java-exception) ())
THROWABLE
CL-USER> (register-java-exception "java.lang.Throwable" 'throwable)
T
CL-USER> (handler-case
 	     (jnew (jconstructor "java.lang.String" "java.lang.String")
                       (make-immediate-object nil :ref))
 	   (throwable () 'throwable))
THROWABLE
CL-USER> (define-condition null-pointer-exception (throwable) ())
NULL-POINTER-EXCEPTION
CL-USER> (register-java-exception "java.lang.NullPointerException" 'null-pointer-exception)
T
CL-USER> (handler-case
 	     (jnew (jconstructor "java.lang.String" "java.lang.String")
                       (make-immediate-object nil :ref))
 	   (throwable () 'throwable))
THROWABLE
CL-USER> (handler-case
 	     (jnew (jconstructor "java.lang.String" "java.lang.String") 42)
 	   (null-pointer-exception () 'null-pointer-exception)
 	   (throwable () 'throwable))
THROWABLE
CL-USER> (handler-case
 	     (jnew (jconstructor "java.lang.String" "java.lang.String")
 		   (make-immediate-object nil :ref))
 	   (null-pointer-exception () 'null-pointer-exception)
 	   (throwable () 'throwable))
NULL-POINTER-EXCEPTION
CL-USER>

Andras

On Sat, 29 Oct 2005 at 02:30:05 +0200, Andras Simon wrote:
> [Sorry for the late reply; my adsl modem gave up the ghost after a
> power outage, and it took two days to get a replacement.]

Ouch!

> On Thu, 27 Oct 2005, Peter Graves wrote:
>
> > Suppose (for the sake of argument) you do:
> >
> >    (define-condition throwable (java-exception) ())
> >    (register-java-exception "java.lang.Throwable" 'throwable)
> >
> > And then some call to Java throws a NullPointerException (for example).
> >
> > Now, you haven't registered "java.lang.NullPointerException". But from
> > Java's point of view, a NullPointerException _is_ a Throwable, so the
> > condition registered for "java.lang.Throwable" should arguably be
> > signalled.
> >
> > You can't accomplish this with a simple hashtable lookup of
> > "java.lang.NullPointerException". You'd have to walk the list of
> > registered exceptions and check to see if the class of the exception at
> > hand is either identical to, or a subclass of, one of the registered
> > exception classes. And the order in which you walked the list would
> > matter, in exactly the same way the order of catch clauses matters
> > after a try block in Java code.
>
> How about walking the list of superclasses of the exception thrown
> (starting with itself of course), and stop at the first that is
> registered?

That seems reasonable, but of course I haven't actually tried it.

As far as I can see, by the way, jFli itself doesn't have any concept
analogous to REGISTER-JAVA-EXCEPTION.

-Peter

On Sat, 29 Oct 2005 at 12:24:23 +0200, Andras Simon wrote:
> On Fri, 28 Oct 2005, Peter Graves wrote:
> > For example:
> >
> >    CL-USER(1): (jnew (jconstructor "java.lang.String" "java.lang.String")
> >                      (make-immediate-object nil :ref))
> >    Debugger invoked on condition of type JAVA-EXCEPTION:
> >      java.lang.reflect.InvocationTargetException
>
> Since this exception is an artifact of our using reflection behind the
> scenes, I think it would make sense to get the real cause (by
> getCause()) and present that to the user (and also to check that on
> the registered exceptions list). Then we'd have
>
> CL-USER(5): (jnew (jconstructor "java.lang.String" "java.lang.String")
>                        (make-immediate-object nil :ref)) 
> Debugger invoked on condition of type JAVA-EXCEPTION:
>    java.lang.NullPointerException
>          at java.lang.String.<init>(String.java:144) 
> ...
>
> [1] CL-USER(7): (inspect *debug-condition*)
>     0 LAYOUT -----------> #<SYSTEM:LAYOUT {176ED77}>
>     1 FORMAT-CONTROL ---> NIL
>     2 FORMAT-ARGUMENTS -> NIL
>     3 CAUSE ------------> #<JAVA-OBJECT java.lang.NullPointerException {E02FC4}>
>
> and
>
> CL-USER(9): (jnew (jconstructor "java.lang.String" "java.lang.String") 23) 
> Debugger invoked on condition of type JAVA-EXCEPTION:
>    java.lang.IllegalArgumentException: argument type mismatch
>
> [1] CL-USER(10): (inspect *debug-condition*)
>     0 LAYOUT -----------> #<SYSTEM:LAYOUT {176ED77}>
>     1 FORMAT-CONTROL ---> NIL
>     2 FORMAT-ARGUMENTS -> NIL
>     3 CAUSE ------------> #<JAVA-OBJECT java.lang.IllegalArgumentException {600A08}>
>
> Perhaps a good rule of thumb is that exceptions that are in the
> java.lang.reflect package should be replaced with their causes, and
> all other exceptions should be left alone.
>
> One possible problem with this is if the user is doing her own
> reflection.

For what it's worth, jFli only does this for exceptions of class
java.lang.reflect.InvocationTargetException. From jni.lisp:

    (defun handle-exception ()
      (let ((e (exception-occurred)))
        (when (not (fli:null-pointer-p e)) ;allow for safe calling in non-exceptional state
          (exception-clear)
          ;if the exception occurs in the reflection target, we really want that
          (when (is-instance-of e (jni-find-class "java/lang/reflect/InvocationTargetException"))
            (setf e (invocationtargetexception.gettargetexception e)))
          (error "~A" (with-output-to-string (s)
                        (format s "~A~%" (object.tostring e))
                        (do-jarray (x (throwable.getstacktrace e))
                          (format s "~A~%" (object.tostring x))))))))

Makes sense to me.

-Peter

On Sat, 29 Oct 2005 at 15:50:31 +0200, Andras Simon wrote:
> I committed some changes (for JNEW only) in this spirit, so now we
> have
>
> CL-USER> (define-condition throwable (java-exception) ())
> THROWABLE
> CL-USER> (register-java-exception "java.lang.Throwable" 'throwable)
> T
> CL-USER> (handler-case
>  	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>                        (make-immediate-object nil :ref))
>  	   (throwable () 'throwable))
> THROWABLE
> CL-USER> (define-condition null-pointer-exception (throwable) ())
> NULL-POINTER-EXCEPTION
> CL-USER> (register-java-exception "java.lang.NullPointerException"
> 'null-pointer-exception) T CL-USER> (handler-case
>  	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>                        (make-immediate-object nil :ref))
>  	   (throwable () 'throwable))
> THROWABLE
> CL-USER> (handler-case
>  	     (jnew (jconstructor "java.lang.String" "java.lang.String") 42)
>  	   (null-pointer-exception () 'null-pointer-exception)
>  	   (throwable () 'throwable))
> THROWABLE
> CL-USER> (handler-case
>  	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>  		   (make-immediate-object nil :ref))
>  	   (null-pointer-exception () 'null-pointer-exception)
>  	   (throwable () 'throwable))
> NULL-POINTER-EXCEPTION
> CL-USER>

Looks good.

-Peter

On Sun, 30 Oct 2005, Peter Graves wrote:

> On Sat, 29 Oct 2005 at 12:24:23 +0200, Andras Simon wrote:

>> Perhaps a good rule of thumb is that exceptions that are in the
>> java.lang.reflect package should be replaced with their causes, and
>> all other exceptions should be left alone.
>>
>> One possible problem with this is if the user is doing her own
>> reflection.
>
> For what it's worth, jFli only does this for exceptions of class
> java.lang.reflect.InvocationTargetException. From jni.lisp:

I only checked this for JNEW, but there InvocationTargetException is
the only exception that is in the java.lang.reflect package. I put in
getCause() there yesterday. I didn't do this unwrapping for JCALL,
JSTATIC etc. because I haven't encountered InvocationTargetExceptions
there yet. But perhaps it should be done anyway.

Andras

On Sun, 30 Oct 2005, Peter Graves wrote:

> On Sat, 29 Oct 2005 at 15:50:31 +0200, Andras Simon wrote:
>> I committed some changes (for JNEW only) in this spirit, so now we
>> have
>>
>> CL-USER> (define-condition throwable (java-exception) ())
>> THROWABLE
>> CL-USER> (register-java-exception "java.lang.Throwable" 'throwable)
>> T
>> CL-USER> (handler-case
>>  	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>>                        (make-immediate-object nil :ref))
>>  	   (throwable () 'throwable))
>> THROWABLE
>> CL-USER> (define-condition null-pointer-exception (throwable) ())
>> NULL-POINTER-EXCEPTION
>> CL-USER> (register-java-exception "java.lang.NullPointerException"
>> 'null-pointer-exception) T CL-USER> (handler-case
>>  	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>>                        (make-immediate-object nil :ref))
>>  	   (throwable () 'throwable))
>> THROWABLE
>> CL-USER> (handler-case
>>  	     (jnew (jconstructor "java.lang.String" "java.lang.String") 42)
>>  	   (null-pointer-exception () 'null-pointer-exception)
>>  	   (throwable () 'throwable))
>> THROWABLE
>> CL-USER> (handler-case
>>  	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>>  		   (make-immediate-object nil :ref))
>>  	   (null-pointer-exception () 'null-pointer-exception)
>>  	   (throwable () 'throwable))
>> NULL-POINTER-EXCEPTION
>> CL-USER>
>
> Looks good.

In the meantime I changed all the other Java calling functions, not
just JNEW, to use the new scheme. And there are a few related tests
in tests/java-tests.lisp.

Thanks for pointing out this problem!

Andras

On Sun, 30 Oct 2005, Peter Graves wrote:

> As far as I can see, by the way, jFli itself doesn't have any concept
> analogous to REGISTER-JAVA-EXCEPTION.

Perhaps this is because jFLI was abandoned (or rather, transformed
into Foil and then to Clojure) before something like it could get in.
Also, doing stuff like this is so much easier with ABCL.

Andras

On Sun, 30 Oct 2005 at 11:58:49 +0100, Andras Simon wrote:
> On Sun, 30 Oct 2005, Peter Graves wrote:
>
> > As far as I can see, by the way, jFli itself doesn't have any concept
> > analogous to REGISTER-JAVA-EXCEPTION.
>
> Perhaps this is because jFLI was abandoned (or rather, transformed
> into Foil and then to Clojure) before something like it could get in.

Hmmm...

Somehow I failed to recognized that jFli was abandoned. (I think I
would have just called it "quiescent".)

For that matter, Clojure seems fairly quiescent at this point, too (no
commits since June).

I guess we're on our own... ;)

> Also, doing stuff like this is so much easier with ABCL.

Yeah.

-Peter

On Sun, 30 Oct 2005, Peter Graves wrote:

> On Sun, 30 Oct 2005 at 11:58:49 +0100, Andras Simon wrote:
>> On Sun, 30 Oct 2005, Peter Graves wrote:
>>
>>> As far as I can see, by the way, jFli itself doesn't have any concept
>>> analogous to REGISTER-JAVA-EXCEPTION.
>>
>> Perhaps this is because jFLI was abandoned (or rather, transformed
>> into Foil and then to Clojure) before something like it could get in.
>
> Hmmm...
>
> Somehow I failed to recognized that jFli was abandoned. (I think I
> would have just called it "quiescent".)
>
> For that matter, Clojure seems fairly quiescent at this point, too (no
> commits since June).

I hope Rich will tell us more about the status of Clojure these days.

>
> I guess we're on our own... ;)

I thought so, too. But now I checked http://www.weitz.de/rdnzl/ and
http://www.weitz.de/rdnzl/#exceptions in particular, and I think we
needn't feel too isolated :)

Andras

On Sun, 30 Oct 2005 at 11:49:46 +0100, Andras Simon wrote:
> In the meantime I changed all the other Java calling functions, not
> just JNEW, to use the new scheme. And there are a few related tests
> in tests/java-tests.lisp.

Thanks for doing the tests!

I moved WITH-REGISTERED-EXCEPTION from test-utilities.lisp to java-
tests.lisp and #+abcl'ed it, since Allegro runs java-tests.lisp too.

ABCL's cross-implementation test suite is very new, and I haven't
really got the infrastructure 100% nailed down yet, but in general,
things should only go in test-utilities.lisp if they're used by tests
in all (or at least most) of the tested areas.

Helper functions and macros that are used in only one of the test files
should just go in that particular test file.

By the way, I like the idea of WITH-REGISTERED-EXCEPTION, and if we
keep going in this direction, we should probably just put it in
java.lisp.

Or should it be WITH-REGISTERED-EXCEPTIONS, allowing you to specify
multiple registrations at once:

    (with-registered-exceptions
        (("java.lang.Throwable" 'throwable)
         ("java.lang.NullPointerException 'null-pointer-exception))
      (do-something))

-Peter

On Sun, 30 Oct 2005, Peter Graves wrote:

> On Sun, 30 Oct 2005 at 11:49:46 +0100, Andras Simon wrote:
>> In the meantime I changed all the other Java calling functions, not
>> just JNEW, to use the new scheme. And there are a few related tests
>> in tests/java-tests.lisp.
>
> Thanks for doing the tests!
>
> I moved WITH-REGISTERED-EXCEPTION from test-utilities.lisp to java-
> tests.lisp and #+abcl'ed it, since Allegro runs java-tests.lisp too.
>
> ABCL's cross-implementation test suite is very new, and I haven't
> really got the infrastructure 100% nailed down yet, but in general,
> things should only go in test-utilities.lisp if they're used by tests
> in all (or at least most) of the tested areas.
>
> Helper functions and macros that are used in only one of the test files
> should just go in that particular test file.

I'll try to remember (and adhere to) this!

> By the way, I like the idea of WITH-REGISTERED-EXCEPTION, and if we
> keep going in this direction, we should probably just put it in
> java.lisp.
>
> Or should it be WITH-REGISTERED-EXCEPTIONS, allowing you to specify
> multiple registrations at once:
>
>    (with-registered-exceptions
>        (("java.lang.Throwable" 'throwable)
>         ("java.lang.NullPointerException 'null-pointer-exception))
>      (do-something))

If something like it ever gets in java.lisp, it should definitely take
this form. But I don't see any general use for it. Do you? If it also
saved and restored the previous state, that would seem more useful, but
I'm afraid it'd also be a step in the direction we agreed not to go...

Andras

On Sun, 30 Oct 2005 at 13:19:05 +0100, Andras Simon wrote:
> > By the way, I like the idea of WITH-REGISTERED-EXCEPTION, and if we
> > keep going in this direction, we should probably just put it in
> > java.lisp.
> >
> > Or should it be WITH-REGISTERED-EXCEPTIONS, allowing you to specify
> > multiple registrations at once:
> >
> >    (with-registered-exceptions
> >        (("java.lang.Throwable" 'throwable)
> >         ("java.lang.NullPointerException 'null-pointer-exception))
> >      (do-something))
>
> If something like it ever gets in java.lisp, it should definitely take
> this form. But I don't see any general use for it. Do you? If it also
> saved and restored the previous state, that would seem more useful, but
> I'm afraid it'd also be a step in the direction we agreed not to go...

Good point. Thanks for reminding me!

I think my jury is still out on a lot of this stuff, actually. That
might be one of the reasons I keep forgetting our previous conclusions.
(Old age is definitely a more important reason, however.)

In any case, we can leave WITH-REGISTERED-EXCEPTIONS in java-tests.lisp
for now.

-Peter

On Fri, 28 Oct 2005, Peter Graves wrote:

> On Thu, 27 Oct 2005 at 05:27:45 -0700, Peter Graves wrote:
>> For the moment, I think I'm going to leave the registration mechanism
>> as it is, except that I do plan to introduce a JavaException class,
>> more or less as we've discussed it, and make sure that when no
>> exceptions are registered, Java exceptions are caught and a well-formed
>> JavaException (or JAVA-EXCEPTION) is signalled on the Lisp side, with a
>> plausible error message.
>
> Done.
>
> For example:
>
>    CL-USER(1): (jnew (jconstructor "java.lang.String" "java.lang.String")
>                      (make-immediate-object nil :ref))
>    Debugger invoked on condition of type JAVA-EXCEPTION:
>      java.lang.reflect.InvocationTargetException
>            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>            at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
>            at org.armedbear.lisp.Java$9.execute(Java.java:376)
>            at org.armedbear.lisp.Primitive.execute(Primitive.java:102)
>            at org.armedbear.lisp.LispThread.execute(LispThread.java:621)
>            at org.armedbear.lisp.Lisp.evalCall(Lisp.java:424)
>            at org.armedbear.lisp.Lisp.eval(Lisp.java:391)
>            at org.armedbear.lisp.Primitives$16.execute(Primitives.java:268)
>            at org.armedbear.lisp.LispThread.execute(LispThread.java:603)
>            at org.armedbear.lisp.Lisp.evalCall(Lisp.java:418)
>            at org.armedbear.lisp.Lisp.eval(Lisp.java:391)
>            at org.armedbear.lisp.Primitives$136.execute(Primitives.java:3378)
>            at org.armedbear.lisp.Lisp.eval(Lisp.java:380)
>            at org.armedbear.lisp.Closure.execute(Closure.java:388)
>            at org.armedbear.lisp.LispThread.execute(LispThread.java:603)
>            at org.armedbear.lisp.Lisp$1.execute(Lisp.java:250)
>            at org.armedbear.lisp.Symbol.execute(Symbol.java:666)
>            at org.armedbear.lisp.LispThread.execute(LispThread.java:603)
>            at org.armedbear.lisp.top_level_44.execute(top-level.lisp:390)
>            at org.armedbear.lisp.CompiledFunction.execute(CompiledFunction.java:51)
>            at org.armedbear.lisp.Symbol.execute(Symbol.java:656)
>            at org.armedbear.lisp.LispThread.execute(LispThread.java:586)
>            at org.armedbear.lisp.top_level_45.execute(top-level.lisp:399)
>            at org.armedbear.lisp.LispThread.execute(LispThread.java:586)
>            at org.armedbear.lisp.Interpreter.run(Interpreter.java:361)
>            at org.armedbear.lisp.Main.main(Main.java:32)
>    Caused by: java.lang.NullPointerException
>            at java.lang.String.<init>(String.java:141)
>            ... 28 more
>    Restarts:
>      0: TOP-LEVEL Return to top level.
>    [1] CL-USER(2): (describe *debug-condition*)
>    #<JAVA-EXCEPTION {E38FAE}> is an object of type JAVA-EXCEPTION.
>    [1] CL-USER(3): (inspect *debug-condition*)
>       0 LAYOUT -----------> #<SYSTEM:LAYOUT {1EDC290}>
>       1 FORMAT-CONTROL ---> NIL
>       2 FORMAT-ARGUMENTS -> NIL
>       3 CAUSE ------------> #<JAVA-OBJECT java.lang.reflect.InvocationTargetException {80B973}>
>    [2i] CL-USER(4): :reset
>    CL-USER(5):

There are a few things that I don't understand about this. Why don't
conditions that are subclasses of JAVA-EXCEPTION inherit the cause
slot? And where does the message disappear? It is passed to signal, as
in

  signal(condition, new SimpleString(getMessage(t)))

Is any of this related to my messing with exceptions?

Ideally, what I think should happen is that any condition that is a
subtype of JAVA-EXCEPTION has a CAUSE and a MESSAGE slot (with readers
and all), and they get filled in when the condition is signaled.

How could I arrange this?

Andras

On Sun, 30 Oct 2005 at 13:40:05 +0100, Andras Simon wrote:
> There are a few things that I don't understand about this. Why don't
> conditions that are subclasses of JAVA-EXCEPTION inherit the cause
> slot?

They do:

    CL-USER(1): (define-condition throwable (java-exception) ())
    THROWABLE
    CL-USER(2): (signal 'throwable)
    Debugger invoked on condition of type THROWABLE:
      #<THROWABLE {374956}>
    Restarts:
      0: TOP-LEVEL Return to top level.
    [1] CL-USER(3): (inspect *debug-condition*)
       0 LAYOUT -----------> #<SYSTEM:LAYOUT {1FC1B56}>
       1 CAUSE ------------> #<UNBOUND>
       2 FORMAT-CONTROL ---> #<UNBOUND>
       3 FORMAT-ARGUMENTS -> #<UNBOUND>
    [2i] CL-USER(4): 

> And where does the message disappear? It is passed to signal, as
> in
>
>   signal(condition, new SimpleString(getMessage(t)))

Yes, but that just passes the message to the real SIGNAL, defined in
signal.lisp:

    public static final LispObject signal(LispObject condition, LispObject message)
        throws ConditionThrowable
    {
        return Symbol.SIGNAL.execute(condition, Keyword.MESSAGE, message);
    }

I don't think the :message keyword is used anywhere else, so this
doesn't make much sense, and that signal() function should go away.

The underlying problem is that conditions don't have a MESSAGE slot.

The Java class Condition has a message field:

    protected String message = null;

But that's very old, and dates back to a time when ABCL's conditions
weren't CLOS objects. That field should probably go away too, but there
are vestiges of it in a number of places.

The right way to do things nowadays is to use the FORMAT-CONTROL slot
(via the :format-control initarg), which all instances of subclasses of
CONDITION have.

That said, there's clearly a bug in this area:

    CL-USER(21): (define-condition test-error (program-error) ())
    TEST-ERROR
    CL-USER(23): (error 'test-error :format-control "this is a test")
    Debugger invoked on condition of type TEST-ERROR:

    Debugger invoked on condition of type TYPE-ERROR:
      The value #<UNBOUND> is not of type LIST.
    Restarts:
      0: TOP-LEVEL Return to top level.

I'll try to fix that later today.

> Is any of this related to my messing with exceptions?

I don't think so, since the problem occurs with conditions derived from
PROGRAM-ERROR too.

> Ideally, what I think should happen is that any condition that is a
> subtype of JAVA-EXCEPTION has a CAUSE and a MESSAGE slot (with readers
> and all), and they get filled in when the condition is signaled.

The CAUSE slot should be there, and JAVA:JAVA-EXCEPTION-CAUSE is the
reader for it.

As mentioned, there is no MESSAGE slot.

> How could I arrange this?

I'll let you know after I figure out what the bug is.

Stay tuned... :)

-Peter

On Oct 30, 2005, at 6:34 AM, Andras Simon wrote:

>
>
> On Sun, 30 Oct 2005, Peter Graves wrote:
>
>
>> On Sun, 30 Oct 2005 at 11:58:49 +0100, Andras Simon wrote:
>>
>>> On Sun, 30 Oct 2005, Peter Graves wrote:
>>>
>>>
>>>> As far as I can see, by the way, jFli itself doesn't have any  
>>>> concept
>>>> analogous to REGISTER-JAVA-EXCEPTION.
>>>>
>>>
>>> Perhaps this is because jFLI was abandoned (or rather, transformed
>>> into Foil and then to Clojure) before something like it could get  
>>> in.
>>>
>>
>> Hmmm...
>>
>> Somehow I failed to recognized that jFli was abandoned. (I think I
>> would have just called it "quiescent".)
>>
>> For that matter, Clojure seems fairly quiescent at this point, too  
>> (no
>> commits since June).
>>
>
> I hope Rich will tell us more about the status of Clojure these days.

Well, nothing has been 'abandoned', but being one person with a  
limited amount of spare time (none currently) I have to focus my  
effort. None of my projects has seen significant interest or input,  
and I would characterize the number of people in the CL community who  
care about Java integration as very small - perhaps they are all  
working on/with ABCL :)

Nevertheless, I am still actively engaged in how best to integrate  
Lisp and the JVM/CLR and intend to continue to contribute to this  
area when I have time.

Re: Clojure - I have reached the point where I am planning support  
for defining Java/CLR classes etc and have realized that this is  
something I should have implemented first. While I only have a small  
amount of Java runtime lib code, if Clojure itself were capable of  
generating decent Java classes and calls, ideally I should have none  
(bootstrap issues aside). I am always surprised at the inordinate  
amount of Java code in Lisp-in-Java implementations and I think this  
is because they, too, added this later in the game. Otherwise, why  
write so much Java? - the whole reason we do these things is so at  
the end of the day we won't have to.

I am also questioning whether or not I can get the level of  
integration that I desire, and that is expected by the not-already-CL- 
users community, and remain CL compatible. I've only attempted a very  
small subset of CL in Clojure, but still encounter thorny issues esp.  
as relates to unifying the type systems. The conversions and wrappers  
of jFli are convenient and fun, and as long as you are using  
reflection the performance overhead is a non-issue, but when you are  
compiling it's a different story.

Some of the things I am contending with in Clojure are:

Should aref work on Java arrays?
When calling a Java function that returns a string, do you get a Lisp  
string or a Java string?
Should the non-mutating string library functions be made to work on  
Java strings?
Should the generic function system be able to dispatch on Java types  
(i.e. not wrappers)?
Can (some of) the sequence functions be made to work on Java  
collections?
How does conditional logic handle Java null? Java booleans?
etc.

The fact is that CL has 'closed-over' much of its type system and is  
not really extensible in many areas. Which leaves all CL-compatible  
approaches having to deal with Java via an FFI such as jFli or  
jLinker, and thus a lot of jthis and jthat, conversions, wrappers  
etc. I had hoped to avoid much of that in Clojure, but I'm not sure I  
can and remain a proper CL subset that supports interactive  
development via Foil. So, I'm thinking, thus the quiescence.

I am not interested in re-inventing wheels, and with its license  
change, I am happy to see ABCL dominate the CL-in-Java space. I would  
be very excited to see it adopt some Java calling primitives it would  
guarantee would compile into efficient direct Java calls, as well as  
compile-time Java class definition syntax (at which point I might  
become a serious user). I think ABCL is stunning in it's level of CL  
conformance, and is the logical home for the (hopefully compilable)  
future of jFli.

Rich

On Sun, 30 Oct 2005 at 11:58:55 -0500, Rich Hickey wrote:
> Well, nothing has been 'abandoned', but being one person with a  
> limited amount of spare time (none currently) I have to focus my  
> effort. None of my projects has seen significant interest or input,  
> and I would characterize the number of people in the CL community who  
> care about Java integration as very small - perhaps they are all  
> working on/with ABCL :)
>
> Nevertheless, I am still actively engaged in how best to integrate  
> Lisp and the JVM/CLR and intend to continue to contribute to this  
> area when I have time.

Excellent!

> Re: Clojure - I have reached the point where I am planning support  
> for defining Java/CLR classes etc and have realized that this is  
> something I should have implemented first. While I only have a small  
> amount of Java runtime lib code, if Clojure itself were capable of  
> generating decent Java classes and calls, ideally I should have none  
> (bootstrap issues aside). I am always surprised at the inordinate  
> amount of Java code in Lisp-in-Java implementations and I think this  
> is because they, too, added this later in the game. Otherwise, why  
> write so much Java? - the whole reason we do these things is so at  
> the end of the day we won't have to.

The bootstrap issues can be formidable.

My experience has been that it has proved very useful during ABCL's
development to have its core written in pure Java, even though it's a
bit annoying to have to deal with such a large body of Java code.

> I am also questioning whether or not I can get the level of  
> integration that I desire, and that is expected by the not-already-CL- 
> users community, and remain CL compatible. I've only attempted a very  
> small subset of CL in Clojure, but still encounter thorny issues esp.  
> as relates to unifying the type systems. The conversions and wrappers  
> of jFli are convenient and fun, and as long as you are using  
> reflection the performance overhead is a non-issue, but when you are  
> compiling it's a different story.
>
> Some of the things I am contending with in Clojure are:
>
> Should aref work on Java arrays?
> When calling a Java function that returns a string, do you get a Lisp  
> string or a Java string?
> Should the non-mutating string library functions be made to work on  
> Java strings?
> Should the generic function system be able to dispatch on Java types  
> (i.e. not wrappers)?
> Can (some of) the sequence functions be made to work on Java  
> collections?
> How does conditional logic handle Java null? Java booleans?
> etc.
>
> The fact is that CL has 'closed-over' much of its type system and is  
> not really extensible in many areas. Which leaves all CL-compatible  
> approaches having to deal with Java via an FFI such as jFli or  
> jLinker, and thus a lot of jthis and jthat, conversions, wrappers  
> etc. I had hoped to avoid much of that in Clojure, but I'm not sure I  
> can and remain a proper CL subset that supports interactive  
> development via Foil. So, I'm thinking, thus the quiescence.
>
> I am not interested in re-inventing wheels, and with its license  
> change, I am happy to see ABCL dominate the CL-in-Java space. I would  
> be very excited to see it adopt some Java calling primitives it would  
> guarantee would compile into efficient direct Java calls, as well as  
> compile-time Java class definition syntax (at which point I might  
> become a serious user). I think ABCL is stunning in it's level of CL  
> conformance, and is the logical home for the (hopefully compilable)  
> future of jFli.

I can certainly see reasons why one would want to call Java code from
Lisp (the obvious one being to be able to use library code that would
otherwise not be available), but not being much of a Java programmer, I
have a harder time imagining why one would want to write a non-trivial
Java class in Lisp when Lisp code can be compiled to efficient JVM
bytecode directly.

Of course you'd want to be able to implement an interface and be able
to do callbacks and handle events, but it seems like these things can
be done with relatively simple wrappers. Maybe I'm wrong about that.
(And I'm probably ignoring some large class of applications that have
totally different requirements.)

In any event, my bias made a lot of decisions easy. ABCL is a full
Common Lisp and uses the CL type system, for better or worse; the Java
type system is not visible to Lisp. A LispObject is not identical to a
java.lang.Object. Strings are mutable. The Lisp side sees only
LispObjects, never a Java null or a Java boolean or a Java array or a
Java collection.

One of the design goals is that a user seeing just the repl should not
even be aware that ABCL is implemented in Java.

I've just started to look at the issue of having ABCL's compiler
generate efficient direct Java calls, using the JCALL/JMETHOD stuff. I
still don't think it's much of a problem, but I have no proof of that
yet either.

On the other hand, it's clear that there will always be at least a
little overhead when you cross the Lisp/Java boundary, in either
direction. That doesn't bother me; I don't cross it much.

In the event that I actually need to define a real Java class, I'll
probably just do it in Java.

That shouldn't be taken to mean that ABCL won't ever provide some way
of defining a real Java class. I do want to get rid of the ASM
dependency in JNEW-RUNTIME-CLASS and friends, and a class definition
syntax (is it really a syntax?) may fall out of that work.

-Peter

Rich Hickey <rich@...> writes:

> Should aref work on Java arrays?
> When calling a Java function that returns a string, do you get a Lisp
> string or a Java string?
> Should the non-mutating string library functions be made to work on
> Java strings?
> Should the generic function system be able to dispatch on Java types
> (i.e. not wrappers)?
> Can (some of) the sequence functions be made to work on Java
> collections?
> How does conditional logic handle Java null? Java booleans?
> etc.

$0.02

One approach that might work in these areas is to use CLOS liberally.
aref could be a generic function.  position, find, etc. could be a
generic functions.  If you've got this, then it's pretty easy to slip
java types in there.  And it's cool.

So I am saying yes, the generic function function system should be
able to dispatch on Java types.

-russ

On Sun, 30 Oct 2005 at 05:31:38 -0800, Peter Graves wrote:
> That said, there's clearly a bug in this area:
>
>     CL-USER(21): (define-condition test-error (program-error) ())
>     TEST-ERROR
>     CL-USER(23): (error 'test-error :format-control "this is a test")
>     Debugger invoked on condition of type TEST-ERROR:
>
>     Debugger invoked on condition of type TYPE-ERROR:
>       The value #<UNBOUND> is not of type LIST.
>     Restarts:
>       0: TOP-LEVEL Return to top level.
>
> I'll try to fix that later today.

It turned out not to be so easy.

There are some serious inconsistencies in the condition system, and I'd
like to fix them properly.

I expect this will take a few days, at a minimum.

-Peter

On Mon, 31 Oct 2005 at 05:12:56 -0800, Peter Graves wrote:
> On Sun, 30 Oct 2005 at 05:31:38 -0800, Peter Graves wrote:
> > That said, there's clearly a bug in this area:
> >
> >     CL-USER(21): (define-condition test-error (program-error) ())
> >     TEST-ERROR
> >     CL-USER(23): (error 'test-error :format-control "this is a test")
> >     Debugger invoked on condition of type TEST-ERROR:
> >
> >     Debugger invoked on condition of type TYPE-ERROR:
> >       The value #<UNBOUND> is not of type LIST.
> >     Restarts:
> >       0: TOP-LEVEL Return to top level.
> >
> > I'll try to fix that later today.
>
> It turned out not to be so easy.
>
> There are some serious inconsistencies in the condition system, and I'd
> like to fix them properly.
>
> I expect this will take a few days, at a minimum.

This is now fixed in CVS:

    CL-USER(1): (define-condition test-error (program-error) ())
    TEST-ERROR
    CL-USER(2): (error 'test-error :format-control "this is a test")
    Debugger invoked on condition of type TEST-ERROR:
      this is a test
    Restarts:
      0: TOP-LEVEL Return to top level.
    [1] CL-USER(3): 

With the latest changes, the condition system is in considerably better
shape overall, but there's still a bit of cleanup to be done.

Thanks for your patience.

-Peter

On Fri, 4 Nov 2005, Peter Graves wrote:

> On Mon, 31 Oct 2005 at 05:12:56 -0800, Peter Graves wrote:
>> On Sun, 30 Oct 2005 at 05:31:38 -0800, Peter Graves wrote:
>>> That said, there's clearly a bug in this area:
>>>
>>>     CL-USER(21): (define-condition test-error (program-error) ())
>>>     TEST-ERROR
>>>     CL-USER(23): (error 'test-error :format-control "this is a test")
>>>     Debugger invoked on condition of type TEST-ERROR:
>>>
>>>     Debugger invoked on condition of type TYPE-ERROR:
>>>       The value #<UNBOUND> is not of type LIST.
>>>     Restarts:
>>>       0: TOP-LEVEL Return to top level.
>>>
>>> I'll try to fix that later today.
>>
>> It turned out not to be so easy.
>>
>> There are some serious inconsistencies in the condition system, and I'd
>> like to fix them properly.
>>
>> I expect this will take a few days, at a minimum.
>
> This is now fixed in CVS:
>
>    CL-USER(1): (define-condition test-error (program-error) ())
>    TEST-ERROR
>    CL-USER(2): (error 'test-error :format-control "this is a test")
>    Debugger invoked on condition of type TEST-ERROR:
>      this is a test
>    Restarts:
>      0: TOP-LEVEL Return to top level.
>    [1] CL-USER(3):
>
> With the latest changes, the condition system is in considerably better
> shape overall, but there's still a bit of cleanup to be done.

This is great news!

But I get this while doing a full compile:

Primitives.java:3913: cannot find symbol
symbol  : constructor TypeError(org.armedbear.lisp.LispObject,java.lang.String)
location: class org.armedbear.lisp.TypeError
             return signal(new TypeError(arg, "output stream"));
                           ^
Closure.java:1166: cannot find symbol
symbol  : constructor TypeError(org.armedbear.lisp.LispObject,java.lang.String)
location: class org.armedbear.lisp.TypeError
             return signal(new TypeError(arg, "closure"));
                           ^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
2 errors
Build failed.

Andras

On Sun, 30 Oct 2005 at 13:40:05 +0100, Andras Simon wrote:
> There are a few things that I don't understand about this. Why don't
> conditions that are subclasses of JAVA-EXCEPTION inherit the cause
> slot? And where does the message disappear? It is passed to signal, as
> in
>
>   signal(condition, new SimpleString(getMessage(t)))

I've fixed signal() at Lisp.java:303 to use the :FORMAT-CONTROL
initarg, which ABCL (like Allegro) supports for CONDITIONs as well as
SIMPLE-CONDITIONs:

    public static final LispObject signal(LispObject condition, LispObject message)
        throws ConditionThrowable
    {
        return Symbol.SIGNAL.execute(condition, Keyword.FORMAT_CONTROL, message);
    }

where the first argument is normally a symbol designating a subtype of
CONDITION. This is what you'd do in Java to get the equivalent of:

    (signal 'some-condition :format-control "some message")

The calls to signal() in Java.java now work more or less as intended.

> Ideally, what I think should happen is that any condition that is a
> subtype of JAVA-EXCEPTION has a CAUSE and a MESSAGE slot (with readers
> and all), and they get filled in when the condition is signaled.
>
> How could I arrange this?

There is no MESSAGE slot, but there is a FORMAT-CONTROL slot, which
should amount to the same thing, if you don't supply any FORMAT-
ARGUMENTS.

There is a CAUSE slot, but the code that does the signalling in
Java.java needs to be changed to initialize that slot when the
condition object is constructed, unless it's constructed by the
JavaException constructor, which is not called for subclasses of
JavaException defined by DEFINE-CONDITION.

There's a fundamental (and, I think, necessary) schizophrenia in ABCL's
condition system: conditions defined in the *.java source files are
instanceof Condition, but conditions defined by DEFINE-CONDITION are
normal STANDARD-OBJECTs.

Something along the lines of (completely untested):

    catch (Throwable t) {
        Class tClass = t.getClass();
        Symbol condition = getCondition(t.getClass());
        if (condition == null)
            // The cause slot gets initialized by the JavaException
            // constructor here, since we're calling it directly.
            signal(new JavaException(t));
        else
            // But here you have to do it by hand, since we're really
            // constructing a STANDARD-OBJECT.
            //signal(condition, new SimpleString(getMessage(t)));
            Symbol.SIGNAL.execute(
                condition,
                Keyword.CAUSE,
                new JavaObject(t),
                Keyword.FORMAT_CONTROL,
                new SimpleString(getMessage(t)));
    }

In the second case, you probably also want to verify that the condition
you're about to signal is a subclass of JAVA-EXCEPTION before you pass
it the :CAUSE initarg, since otherwise it won't have that slot.

I also changed the registered exception map to be a normal HashMap.
Initially I did this because I was trying to pin down some non-
deterministic behavior involving the string that gets returned by
getMessage(t), but it turns out that the non-determinism is caused by
HotSpot's just-in-time compilation of the code in question. I don't
think we need a WeakHashMap in any case, since the map is never going
to be very big, and in most cases everything in it will be hanging
around for other reasons anyway.

-Peter

On Fri, 4 Nov 2005 at 21:30:36 +0100, Andras Simon wrote:
> But I get this while doing a full compile:
>
> Primitives.java:3913: cannot find symbol
> symbol  : constructor
> TypeError(org.armedbear.lisp.LispObject,java.lang.String) location:
> class org.armedbear.lisp.TypeError
>              return signal(new TypeError(arg, "output stream"));
>                            ^
> Closure.java:1166: cannot find symbol
> symbol  : constructor
> TypeError(org.armedbear.lisp.LispObject,java.lang.String) location:
> class org.armedbear.lisp.TypeError
>              return signal(new TypeError(arg, "closure"));
>                            ^
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 2 errors
> Build failed.

Looks like I forgot to check in Primitives.java (and Closure.java).

Should be fixed now.

Sorry!

-Peter

On Fri, 4 Nov 2005, Peter Graves wrote:

>
> Looks like I forgot to check in Primitives.java (and Closure.java).
>
> Should be fixed now.

It is. Thanks,

Andras

On Fri, 4 Nov 2005, Peter Graves wrote:

>
> There's a fundamental (and, I think, necessary) schizophrenia in ABCL's
> condition system: conditions defined in the *.java source files are
> instanceof Condition, but conditions defined by DEFINE-CONDITION are
> normal STANDARD-OBJECTs.
>

Is this the reason for the following?

CL-USER(1): (define-condition throwable (java-exception) ())
THROWABLE
CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable)
T
CL-USER(3): (handler-case
              (jnew (jconstructor "java.lang.String" "java.lang.String")
                       (make-immediate-object nil :ref))
            (throwable (c) c))
#<THROWABLE {F1CDFB}>
CL-USER(4): (java-exception-cause *)
Debugger invoked on condition of type TYPE-ERROR:
   The value #<THROWABLE {F1CDFB}> is not of type JAVA-EXCEPTION.
Restarts:
   0: TOP-LEVEL Return to top level.
[1] CL-USER(5): :res
CL-USER(6): (typep * 'java-exception)
T
CL-USER(7):

That there is an error is fine, since I haven't updated Java.java. (I
plan to do that soon, by the way.)  But the message is quite
misleading.

Andras

On Sun, 6 Nov 2005 at 19:52:00 +0100, Andras Simon wrote:
> On Fri, 4 Nov 2005, Peter Graves wrote:
> > There's a fundamental (and, I think, necessary) schizophrenia in ABCL's
> > condition system: conditions defined in the *.java source files are
> > instanceof Condition, but conditions defined by DEFINE-CONDITION are
> > normal STANDARD-OBJECTs.
> >
>
> Is this the reason for the following?
>
> CL-USER(1): (define-condition throwable (java-exception) ())
> THROWABLE
> CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable)
> T
> CL-USER(3): (handler-case
>               (jnew (jconstructor "java.lang.String" "java.lang.String")
>                        (make-immediate-object nil :ref))
>             (throwable (c) c))
> #<THROWABLE {F1CDFB}>
> CL-USER(4): (java-exception-cause *)
> Debugger invoked on condition of type TYPE-ERROR:
>    The value #<THROWABLE {F1CDFB}> is not of type JAVA-EXCEPTION.
> Restarts:
>    0: TOP-LEVEL Return to top level.
> [1] CL-USER(5): :res
> CL-USER(6): (typep * 'java-exception)
> T
> CL-USER(7):
>
> That there is an error is fine, since I haven't updated Java.java. (I
> plan to do that soon, by the way.)  But the message is quite
> misleading.

Yes, JAVA-EXCEPTION-CAUSE was expecting its argument to be instanceof
Condition, but a THROWABLE is just a STANDARD-OBJECT.

Fixing that bug exposed a printing bug with UNBOUND-SLOT conditions,
which I've also fixed.

So now it works (or at least signals a plausible error):

    CL-USER(1): (define-condition throwable (java-exception) ())
    THROWABLE
    CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable)
    T
    CL-USER(3): (handler-case
                  (jnew (jconstructor "java.lang.String" "java.lang.String")
                           (make-immediate-object nil :ref))
                (throwable (c) c))
    #<THROWABLE {1ABA308}>
    CL-USER(4): (java-exception-cause *)
    Debugger invoked on condition of type UNBOUND-SLOT:
      The slot SYSTEM::CAUSE is unbound in the object #<THROWABLE {1ABA308}>.
    Restarts:
      0: TOP-LEVEL Return to top level.
    [1] CL-USER(5): 

There are probably more bugs like this lurking in the condition system,
pending the completion of a thorough cleanup pass.

-Peter

On Sun, 6 Nov 2005, Peter Graves wrote:

>
> Yes, JAVA-EXCEPTION-CAUSE was expecting its argument to be instanceof
> Condition, but a THROWABLE is just a STANDARD-OBJECT.
>
> Fixing that bug exposed a printing bug with UNBOUND-SLOT conditions,
> which I've also fixed.
>
> So now it works (or at least signals a plausible error):
>
>    CL-USER(1): (define-condition throwable (java-exception) ())
>    THROWABLE
>    CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable)
>    T
>    CL-USER(3): (handler-case
>                  (jnew (jconstructor "java.lang.String" "java.lang.String")
>                           (make-immediate-object nil :ref))
>                (throwable (c) c))
>    #<THROWABLE {1ABA308}>
>    CL-USER(4): (java-exception-cause *)
>    Debugger invoked on condition of type UNBOUND-SLOT:
>      The slot SYSTEM::CAUSE is unbound in the object #<THROWABLE {1ABA308}>.
>    Restarts:
>      0: TOP-LEVEL Return to top level.
>    [1] CL-USER(5):
>

Perfect!

> There are probably more bugs like this lurking in the condition system,
> pending the completion of a thorough cleanup pass.

Is this one of them?

CL-USER> (define-condition throwable (java-exception) ())
THROWABLE
CL-USER> (register-java-exception "java.lang.Throwable" 'throwable)
T
CL-USER> (handler-case
 	     (jnew (jconstructor "java.lang.String" "java.lang.String")
                       (make-immediate-object nil :ref))
 	   (throwable (c) c))
#<THROWABLE {1F72D0}>
CL-USER> (typep * 'simple-condition)
NIL
CL-USER> (simple-condition-format-control **)
"java.lang.NullPointerException"

[I've just committed the changes you suggested two days ago, that's
how "java.lang.NullPointerException" got in the FORMAT-CONTROL slot.]

In other words: should conditions that inherit from JAVA-EXCEPTION be
SIMPLE-CONDITIONs?

Andras

On Sun, 6 Nov 2005, Andras Simon wrote:

>
>
> On Sun, 6 Nov 2005, Peter Graves wrote:
>
>> 
>> Yes, JAVA-EXCEPTION-CAUSE was expecting its argument to be instanceof
>> Condition, but a THROWABLE is just a STANDARD-OBJECT.
>> 
>> Fixing that bug exposed a printing bug with UNBOUND-SLOT conditions,
>> which I've also fixed.
>> 
>> So now it works (or at least signals a plausible error):
>> 
>>    CL-USER(1): (define-condition throwable (java-exception) ())
>>    THROWABLE
>>    CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable)
>>    T
>>    CL-USER(3): (handler-case
>>                  (jnew (jconstructor "java.lang.String" 
>> "java.lang.String")
>>                           (make-immediate-object nil :ref))
>>                (throwable (c) c))
>>    #<THROWABLE {1ABA308}>
>>    CL-USER(4): (java-exception-cause *)
>>    Debugger invoked on condition of type UNBOUND-SLOT:
>>      The slot SYSTEM::CAUSE is unbound in the object #<THROWABLE 
>> {1ABA308}>.
>>    Restarts:
>>      0: TOP-LEVEL Return to top level.
>>    [1] CL-USER(5):
>> 
>
> Perfect!
>
>> There are probably more bugs like this lurking in the condition system,
>> pending the completion of a thorough cleanup pass.
>
> Is this one of them?
>
> CL-USER> (define-condition throwable (java-exception) ())
> THROWABLE
> CL-USER> (register-java-exception "java.lang.Throwable" 'throwable)
> T
> CL-USER> (handler-case
> 	     (jnew (jconstructor "java.lang.String" "java.lang.String")
>                      (make-immediate-object nil :ref))
> 	   (throwable (c) c))
> #<THROWABLE {1F72D0}>
> CL-USER> (typep * 'simple-condition)
> NIL
> CL-USER> (simple-condition-format-control **)
> "java.lang.NullPointerException"
>
> [I've just committed the changes you suggested two days ago, that's
> how "java.lang.NullPointerException" got in the FORMAT-CONTROL slot.]
>
> In other words: should conditions that inherit from JAVA-EXCEPTION be
> SIMPLE-CONDITIONs?

I've just noticed that you wrote in the same mail I referred to above

| I've fixed signal() at Lisp.java:303 to use the :FORMAT-CONTROL
| initarg, which ABCL (like Allegro) supports for CONDITIONs as well as
| SIMPLE-CONDITIONs:

Sorry for the noise!

Andras

On Fri, 4 Nov 2005, Peter Graves wrote:

>
> Something along the lines of (completely untested):
>
>    catch (Throwable t) {
>        Class tClass = t.getClass();
>        Symbol condition = getCondition(t.getClass());
>        if (condition == null)
>            // The cause slot gets initialized by the JavaException
>            // constructor here, since we're calling it directly.
>            signal(new JavaException(t));
>        else
>            // But here you have to do it by hand, since we're really
>            // constructing a STANDARD-OBJECT.
>            //signal(condition, new SimpleString(getMessage(t)));
>            Symbol.SIGNAL.execute(
>                condition,
>                Keyword.CAUSE,
>                new JavaObject(t),
>                Keyword.FORMAT_CONTROL,
>                new SimpleString(getMessage(t)));
>    }

It's tested now :)

>
> In the second case, you probably also want to verify that the condition
> you're about to signal is a subclass of JAVA-EXCEPTION before you pass
> it the :CAUSE initarg, since otherwise it won't have that slot.

Perhaps the best place for this check would be in Java.getCondition().
In any case, I could do with some help on how to do this, because I
don't even know to get the condition associated with a symbol on the
Java side.

Andras

On Mon, 7 Nov 2005 at 01:29:37 +0100, Andras Simon wrote:
> On Fri, 4 Nov 2005, Peter Graves wrote:
> > In the second case, you probably also want to verify that the condition
> > you're about to signal is a subclass of JAVA-EXCEPTION before you pass
> > it the :CAUSE initarg, since otherwise it won't have that slot.
>
> Perhaps the best place for this check would be in Java.getCondition().
> In any case, I could do with some help on how to do this, because I
> don't even know to get the condition associated with a symbol on the
> Java side.

Suppose you've done (for example):

    (in-package #:cl-user)
    (define-condition throwable (java-exception) ())

You can then use MAKE-CONDITION to get a condition instance:

    (make-condition 'throwable)

The same thing in Java would be:

    LispObject condition =
        Symbol.MAKE_CONDITION.execute(PACKAGE_CL_USER.intern("THROWABLE"));

Or, if what you want is the condition class, rather than an instance:

    LispClass c = 
        LispClass.findClass(PACKAGE_CL_USER.intern("THROWABLE"));

BTW, in Java.getCondition(), it looks like you might be able to save a
call:

     	for (Class c = cl ; c != o ; c = c.getSuperclass())
            if (registeredExceptions.containsKey(c))
                return (Symbol)registeredExceptions.get(c);
        return null;

I think this could be:

     	for (Class c = cl ; c != o ; c = c.getSuperclass()) {
            Object object = registeredExceptions.get(c);
            if (object != null)
                return (Symbol) object;
        }
        return null;

Once again, completely untested... :)

-Peter

On Sun, 6 Nov 2005, Peter Graves wrote:


> Suppose you've done (for example):
>
>    (in-package #:cl-user)
>    (define-condition throwable (java-exception) ())
>
> You can then use MAKE-CONDITION to get a condition instance:
>
>    (make-condition 'throwable)
>
> The same thing in Java would be:
>
>    LispObject condition =
>        Symbol.MAKE_CONDITION.execute(PACKAGE_CL_USER.intern("THROWABLE"));
>
> Or, if what you want is the condition class, rather than an instance:
>
>    LispClass c =
>        LispClass.findClass(PACKAGE_CL_USER.intern("THROWABLE"));


Yes, this last one was the bit I needed. Thanks!

>
> BTW, in Java.getCondition(), it looks like you might be able to save a
> call:
>
>     	for (Class c = cl ; c != o ; c = c.getSuperclass())
>            if (registeredExceptions.containsKey(c))
>                return (Symbol)registeredExceptions.get(c);
>        return null;
>
> I think this could be:
>
>     	for (Class c = cl ; c != o ; c = c.getSuperclass()) {
>            Object object = registeredExceptions.get(c);
>            if (object != null)
>                return (Symbol) object;
>        }
>        return null;

This is how it is now, as it looks more natural now that I also check
whether object is a subclass of JAVA-EXCEPTION.

The code that does the checking isn't very pretty. Some excuses:
  - I'm sure there is a standard way to check (in Java) whether one
  (Lisp) class is a subclass of another, but I couldn't find it.
  - NIL is not a Cons, and that makes going down a list a bit harder
  than usual.
  - I would've liked to have a

private static final LispClass java_exception = LispClass.findClass(Symbol.JAVA_EXCEPTION);

to compare the superclasses of the condition to be signaled with, but
it got initialized too early (?) and ended up being null. So now
java_exception is a local variable in isJavaException [a misleading
name, by the way]. Maybe it would be simpler to check the name of
these classes against Symbol.JAVA_EXCEPTION, but that would mean
slightly more work at runtime.

>
> Once again, completely untested... :)

... but working :)

Andras

On Mon, 7 Nov 2005 at 18:45:57 +0100, Andras Simon wrote:
> The code that does the checking isn't very pretty. Some excuses:
>   - I'm sure there is a standard way to check (in Java) whether one
>   (Lisp) class is a subclass of another, but I couldn't find it.

Before this evening, it wasn't easy to find, but now it is:

    private static boolean isJavaException(LispClass lc)
    {
        return lc.subclassp(LispClass.findClass(Symbol.JAVA_EXCEPTION));
    }

>   - NIL is not a Cons, and that makes going down a list a bit harder
>   than usual.
>   - I would've liked to have a
>
> private static final LispClass java_exception =
> LispClass.findClass(Symbol.JAVA_EXCEPTION);
>
> to compare the superclasses of the condition to be signaled with, but
> it got initialized too early (?) and ended up being null.

I've moved Java.class to the very end of the loadClass() list at the
bottom of Lisp.java, so maybe that will work correctly now.

StandardClass.JAVA_EXCEPTION might work too.

> So now java_exception is a local variable in isJavaException [a
> misleading name, by the way]. Maybe it would be simpler to check the
> name of these classes against Symbol.JAVA_EXCEPTION, but that would
> mean slightly more work at runtime.
>
> >
> > Once again, completely untested... :)
>
> ... but working :)

Great!

-Peter

On Mon, 7 Nov 2005, Peter Graves wrote:

> On Mon, 7 Nov 2005 at 18:45:57 +0100, Andras Simon wrote:
>> The code that does the checking isn't very pretty. Some excuses:
>>   - I'm sure there is a standard way to check (in Java) whether one
>>   (Lisp) class is a subclass of another, but I couldn't find it.
>
> Before this evening, it wasn't easy to find, but now it is:
>
>    private static boolean isJavaException(LispClass lc)
>    {
>        return lc.subclassp(LispClass.findClass(Symbol.JAVA_EXCEPTION));
>    }

Much friendlier!

>> private static final LispClass java_exception =
>> LispClass.findClass(Symbol.JAVA_EXCEPTION);
>>
>> to compare the superclasses of the condition to be signaled with, but
>> it got initialized too early (?) and ended up being null.
>
> I've moved Java.class to the very end of the loadClass() list at the
> bottom of Lisp.java, so maybe that will work correctly now.

It does. Thanks.

I think it's now time to actually use this stuff.

Andras