[armedbear-devel] new jcall / jar:file: path functions

[Alessio Stalla]

On Fri, Jan 8, 2010 at 10:47 PM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> On Fri, Jan 8, 2010 at 4:21 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
>>> Kind of curious: Why are you not just using the jsint implementation?
>>
>> Well, one reason being that their implemetation requires a call to
>> setAccessible() which is defined to be allowed to raise a security
>> exception. The method Alessio implemented (and I figured out long ago
>> in order to implement USOCKET on ABCL) doesn't have that drawback.
>> When this strategy can't work, well, I guess we'll need to revisit and
>> go the security exception route.
>
> If it happens to raise a security exception, one can deal with it
> then. I've used the jsint implementation for a long time now and I
> don't recall that happening once.

My main objection against jsint is that it requires an additional jar
on the classpath, of which it uses just a few classes. But read on.

>>> It's been in use for quite a while and it would certainly make my life
>>> easier to be able to continue to use that interface. For example, I
>>> use their findMethod implementation to get a method so I can optimize
>>> certain loops by avoiding dynamic lookup each time.
>>
>> Right. We want to start doing caching like that too, based on the
>> object class, method name and the argument classes. That would be what
>> you need, right?
>
> Yes. However I am concerned that this is work that need not be done,
> freeing up time to do other things. The jsint implementation does what
> is necessary and is the product of a good deal of thought and
> experience. Seems to me that using mature code is preferable to
> re-implementing stuff.

It is preferable, without objections. However, see the thing from another angle:
we're not trying to replace jsint, just to fix abcl. The previous
implementation of jcall/jstatic was undoubtedly wrong; it would only
consider method arity, not the actual types. We could have forbidden
(jcall "method" ...) and always required (jcall (jmethod ...) ...),
delegating the more advanced stuff to libraries like jsint; we chose
instead to implement it right, overlapping with jsint.
It may be that with time abcl will provide everything jsint provides
now, rendering it obsolete; but until then, and even afterwards, you
can happily continue to use jsint. We don't want to break
compatibility. Also, the effort put into this task has been modest
until now; everything seemed doable with little work. I'm speaking
just for myself, but if implementing even more advanced functionality
proves to be a hard task, I'm considering it as low priority, at best.

Cheers,
Alessio