[armedbear-devel] Alex's reworked jfli.lisp pushed to trunk

[Mark Evenson]

On Jun 12, 2012, at 13:24 , Alex Mizrahi wrote:

> 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.

[…]

> 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.

As per your suggestion I have committed your worked-through version
of 'jfli.lisp' [to ABCL SVN trunk][r13962].  Thanks for the detective
work sorting through all the differences.

[r13962]: http://trac.common-lisp.net/armedbear/changeset/13962

Please pipe up if this breaks your current usage of the abcl-contrib/jfli.

> 
> 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.


I have been in touch via private email with Nick Levine, who maintains
the version of JFLI hosted on SourceForge and was indeed a little
concerned about the widening gyre of JFLI profileration.  We hashed
out a quick plan by which we will first introduce a mechanism for
implementation-specific code, and then morph the abcl-contrib JFLI
to use that mechanism to somehow share an API with the code hosted
on Sourceforge.  The timescale to get this done is on the order of
weeks if not months given my current overcommitment to various
projects, so efforts like Alex's here are more than welcome (i.e.
if you take the version in ABCL trunk, produce a usable diff that
evolves JFLI, and get it back to the mailing list soonish, that
will be more advanced that what I have managed to get done).

--
"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."