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.
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."
armedbear-devel@common-lisp.net
-
Alex Mizrahi -
Mark Evenson