[armedbear-devel] Tentative inclusion of JSS with ABCL contrib
Sick of having Clojure eat ABCL's lunch, I've decided to [start trying to include JSS as an ABCL contrib][1] to bring forward a more public platform for Java interop experiments on ANSI CL. Or at least the example of one such platform. [1]: http://trac.common-lisp.net/armedbear/changeset/13281 I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL Java routines have evolved to a point that none of the external JAR dependencies should be necessary. When jscheme.jar is eliminated, we will be able to load JSS quite comfortably from abcl-contrib.jar (even over the network). With the additional syntax for ASDF, we will be able to start formalizing a packaging mechanism that allows us to mix Lisp/Java libraries in a systematic manner. One question for Alan about the #1"something" form of the JSS macro: is relied on outside of JSS? It seems like it was introduced to get around a bug in abcl-0.18, but doesn't seem to be used anywhere inside the lsw2 code base. I've eliminated it in my port of JSS, but would like confirmation that nothing should be using it. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Fri, May 20, 2011 at 10:38 AM, Mark Evenson <evenson@panix.com> wrote:
Sick of having Clojure eat ABCL's lunch, I've decided to [start trying to include JSS as an ABCL contrib][1] to bring forward a more public platform for Java interop experiments on ANSI CL. Or at least the example of one such platform.
[1]: http://trac.common-lisp.net/armedbear/changeset/13281
I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL Java routines have evolved to a point that none of the external JAR dependencies should be necessary. When jscheme.jar is eliminated, we will be able to load JSS quite comfortably from abcl-contrib.jar (even over the network). With the additional syntax for ASDF, we will be able to start formalizing a packaging mechanism that allows us to mix Lisp/Java libraries in a systematic manner.
One question for Alan about the #1"something" form of the JSS macro: is relied on outside of JSS? It seems like it was introduced to get around a bug in abcl-0.18, but doesn't seem to be used anywhere inside the lsw2 code base. I've eliminated it in my port of JSS, but would like confirmation that nothing should be using it.
Nothing else is using it. Best, Alan
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Fri, May 20, 2011 at 4:38 PM, Mark Evenson <evenson@panix.com> wrote:
Sick of having Clojure eat ABCL's lunch, I've decided to [start trying to include JSS as an ABCL contrib][1] to bring forward a more public platform for Java interop experiments on ANSI CL. Or at least the example of one such platform.
Nice!
I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL Java routines have evolved to a point that none of the external JAR dependencies should be necessary. When jscheme.jar is eliminated, we will be able to load JSS quite comfortably from abcl-contrib.jar (even over the network).
What is jscheme.jar still needed for?
With the additional syntax for ASDF, we will be able to start formalizing a packaging mechanism that allows us to mix Lisp/Java libraries in a systematic manner.
+1 for that! I'd love to have something like Leiningen for Clojure integrated with ASDF, leveraging Maven for dependency resolution (and only for that). e.g. (:depends-on (maven-dep "com.foo" "bar" "1.2.3")). Bye, Alessio
On May 20, 2011, at 5:26 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Fri, May 20, 2011 at 4:38 PM, Mark Evenson <evenson@panix.com> wrote: [.…]
I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL Java routines have evolved to a point that none of the external JAR dependencies should be necessary. When jscheme.jar is eliminated, we will be able to load JSS quite comfortably from abcl-contrib.jar (even over the network).
What is jscheme.jar still needed for?
Not much: I seemed to have successfully ported INVOKE-RESTARGS in my first commit. I think will the subsequent elimination of the #1"something" macro that I was reluctant to do without confirmation from Alan will finish the job. But I have to check a little more thoroughly. It turns out that when you worked on the JCALL methods in imitation ok JSS, you did most (all?) the necessary work on the ABCL side.
With the additional syntax for ASDF, we will be able to start formalizing a packaging mechanism that allows us to mix Lisp/Java libraries in a systematic manner.
+1 for that! I'd love to have something like Leiningen for Clojure integrated with ASDF, leveraging Maven for dependency resolution (and only for that). e.g. (:depends-on (maven-dep "com.foo" "bar" "1.2.3")).
I'd definitely like your ideas on this once I get JSS comfortably loading from its ASDF form packaged in a jar. I intend to create a utility that given ASDF definitions as input, will output systems packaged in a jar or jars. One problem in my current thinking is what to do about the jar-file type in ASDF definitions once they are packaged in a jar. Should we implicitly (or explicitly) rewrite the definition from a filesystem relative location for the jar to something that says "look this up in the classpath"? Or should we include the "Java" jars inside the ASDF jar? The former leads to less than seemless deploment. The later seems grossly inefficient. In some ways, I fear that this sort of dependency packaging is beyond what ASDF can comfortably handle, and that we would need to invent a DSL to describe dependencies on Java libraries, ideally that can export/import from Ivy, Maven, and OSGi descriptions. Would Leiningen be something we should study/adapt in this direction? Sent from my iPad
On Fri, May 20, 2011 at 6:28 PM, Mark Evenson <evenson@panix.com> wrote:
On May 20, 2011, at 5:26 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Fri, May 20, 2011 at 4:38 PM, Mark Evenson <evenson@panix.com> wrote: [.…]
I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most
of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL
Java routines have evolved to a point that none of the external JAR
dependencies should be necessary. When jscheme.jar is eliminated, we will
be able to load JSS quite comfortably from abcl-contrib.jar (even over the
network).
What is jscheme.jar still needed for?
Not much: I seemed to have successfully ported INVOKE-RESTARGS in my first commit. I think will the subsequent elimination of the #1"something" macro that I was reluctant to do without confirmation from Alan will finish the job. But I have to check a little more thoroughly. It turns out that when you worked on the JCALL methods in imitation ok JSS, you did most (all?) the necessary work on the ABCL side.
With the additional syntax for ASDF, we will be able to start
formalizing a packaging mechanism that allows us to mix Lisp/Java libraries
in a systematic manner.
+1 for that! I'd love to have something like Leiningen for Clojure integrated with ASDF, leveraging Maven for dependency resolution (and only for that). e.g. (:depends-on (maven-dep "com.foo" "bar" "1.2.3")).
I'd definitely like your ideas on this once I get JSS comfortably loading from its ASDF form packaged in a jar. I intend to create a utility that given ASDF definitions as input, will output systems packaged in a jar or jars. One problem in my current thinking is what to do about the jar-file type in ASDF definitions once they are packaged in a jar. Should we implicitly (or explicitly) rewrite the definition from a filesystem relative location for the jar to something that says "look this up in the classpath"? Or should we include the "Java" jars inside the ASDF jar? The former leads to less than seemless deploment. The later seems grossly inefficient. In some ways, I fear that this sort of dependency packaging is beyond what ASDF can comfortably handle, and that we would need to invent a DSL to describe dependencies on Java libraries, ideally that can export/import from Ivy, Maven, and OSGi descriptions. Would Leiningen be something we should study/adapt in this direction?
I don't know Leiningen well enough to know; I don't use Clojure, I just lurk on their mailing list a bit. I think though that we should keep dependencies and packaging separated, just like they're now in ASDF for Lisp. ASDF simply fetches dependencies from known places, compiles and loads the code. How you package your software and where you put your dependencies isn't ASDF's business; it just needs to find the dependencies when it needs them. This means that if we go the Maven route it's Maven who downloads and stores libraries in its local repository; ASDF merely adds them to the classpath while compiling/loading. Just like Quicklisp does: it downloads dependencies, puts them somewhere, and tells ASDF where to find them. Except that Quicklisp --uses--> ASDF while I'd like that ASDF --used--> Maven. Alessio
As of [r13303][], the ABCL contribs contain a version of JSS that is not dependent on external jars. [r13303]: http://trac.common-lisp.net/armedbear/changeset/13303 I've revamped the contrib mechanism to automagically load all packaged contrib ASDF definitions as long as "abcl-contrib.jar" ends up in the same directory as "abcl.jar" via the new :ABCL-CONTRIB module. To use, one need to build the 'abcl.contrib' target, and then CL-USER> (require :abcl-contrib) place JSS in the ASDF path. Then CL-USER> (require :jss) will load JSS, compiling if necessary to the ASDF cache. The use of REQUIRE is actually just a shortcut for loading JSS via ASDF so CL-USER> (ASDF:LOAD-SYSTEM :JSS) will do the same thing. I'm calling this jss-2.0.0 because a) it no longer uses JScheme or BeanShell meaning that the underlying implementation has changed and b) because it is now packaged as JSS instead of CL-USER. But other than that, I intend the behavior of jss-2.0.0 to match [jss-1.0][1]. For current users of JSS wishing to ease migration, there is a JSS:ENSURE-COMPATIBILITY function which should pollute^H^H^H^H^Himport CL-USER with the proper JSS symbols. [1]: http://lsw2.googlecode.com/svn/trunk/jss/ For documentation on JSS look the top of 'abcl/contrib/jss/invoke.lisp'. The essential featureis that one gets a macro ('#"') that dynamically introspects all loaded classes for either instance or static methods to call with the instances determined in a DWIM manner. A brief example of JSS usage would be CL-USER> (mapcar #"toString" (jss:set-to-list (#"entrySet" (#"getProperties" 'System)))) would return a Lisp list of all JVM properties as Lisp strings. I would hope that current users of JSS poke around at my repackageing now and consider migrating to the ABCL contrib version when abcl-0.26 is released. I intend to write some standalone documentation on using JSS to get it used by a wider audience, as well as some coverage on the abcl-dev blog. JSS currently includes a extension for including jar files in ASDF definitions. There is no logical necessity for this being part of JSS. The only thing that would need to separate this out into ASDF proper would be to replace JAVA:ADD-TO-CLASSPATH with a generic method that would allow dynamically added classes to be introspected by JSS. When I tackle the project of defining JVM dependencies like jar archives I will preserve the current semantics of JSS ASDF, although the implementation will probably be moved "closer" to core ABCL -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (3)
-
Alan Ruttenberg -
Alessio Stalla -
Mark Evenson