[armedbear-devel] jfli-abcl revisited

[Alex Mizrahi]

hi

Some people mentioned that keeping jfli interface is desirable. Also
I've noticed a problem with Ole's version:
 java array accessor (jref) doesn't do boxing correctly. It isn't a
big deal, but I kinda used that functionality, and I have no idea what
motivated those changes so I don't know to to fix them correctly.

So I went back to original jfli-abcl version by Andras Simon and did
minimal amount of changes to make it work with new version.
Also there are several conservative improvements.

Here it is: https://gist.github.com/2916760#file_jfli.lisp
And here's a diff against jfli-abcl.lisp still available on Andras'
site: https://gist.github.com/2916760#file_jfli_abcl.diff
(This one: http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar )

Here's a description of changes:
1. make-immediate-object is deprecated now, so we use java:+null+ and friends
2. boxing extension by A. Vodonosov is described in comment
3. ensure-java-class was renamed to %ensure-java-class to avoid
collision with java:ensure-java-class which does completely different
thing. (I thought about shadowing it, but I think renaming makes it
clearer.)
4. support for both int and long in overloads (or however they are
called in Java)
5. new-class functionality was commented out because abcl-side
interface have changed. (together with its helper jrc)

As I understand, Alessio already reimplemented jnew-runtime-class, so
we just need some brave soul to adapt code to new APi and implement
missing parts
This isn't particularly hard, I think, but I'm not interested in
new-class at all, so I wouldn't do this.

And for the sake of completeness here's diff between original
jfli-abcl and Ole's version:

https://gist.github.com/2916945

It seems that the major difference is "Ripped out CLOS mirror
support". I have no idea if 'CLOS mirror support' is required
according to jfli spec or it is
useless. Also there is a lot of refactoring. Which is great, but it
can break things...

So again, unless somebody has resources to check Ole's changes and
verify that they adhere to jfli documentation, I recommend replacing
it
with my 'conservative' version in ABCL's contrib repo.

Also, I've noticed that jfli maintainer said it would be cool to merge
different versions, but I don't think it's necessary: the only common
part is
defpackage, pretty much all the code is specific to ABCL. (This was
true for old jfli version, at least.) So it's better to treat jfli as
a specification
rather than as a library.