It turns out that if we pretend that Java 9 and Java 10 never existed, we can run a lightly modified version of [ABCL on Java11][11]. Once I get something stable, that mostly works across both openjdk8 and openjdk11, I think I would like to fork an abcl-2.0.0 while maintaining support for openjdk[678] via the abcl-1.m.n series, Our CL:PATHNAME stuff needs to be adapted because Java11 stops referring to classes in `jar:file` location in favor of a synthetic reference to a `jrt:` path, but I think I may be able to easuly paper over this problem by tightening the isomorphism between a URI and the namestrings for ABCL’s implementation. [11]: https://github.com/armedbear/abcl/pull/96 Surprisingly, the compiler seems to work fine, so the implementation is certainly not intolerably slow under Java 11. JSS certainly does not work but the ABCL-CONTRIB works for implementations with access to a filesystem on which CL:DIRECTORY can work. This patch reworks ABCL-CONTRIB strategy to introspect the value of the the Java system property "java.class.path". This may not be sufficient to find the contribs under all possible ways that the implementation may be hosted. To provide some background to the issues here, ABCL-CONTRIB is deliberately packaged separately from the contents of abcl.jar in order to: • Keep the base ANSI implementation plus the included ASDF version in a single artifact with no other dependencies. • Push the decision to potentially infringe on licenses explicitly to the user. The knowledgable User may use the build-time option for the inclusion of code in system.lisp and the AIO packaging mechanism to create an unified "All-in-one" artifact. Since ASDF is always included as part of the base abcl.jar, we may rely on its presence to find additional artifacts to add as additional code to abcl, aka. "the abcl contribs". Currently, this is achieved by the following strategies, tried sequentially until one is found to be successful: • Introspecting for an implementation of "org.abcl-contrib" as declared in the system jar manifest. • Attempting to locate a jar file named abcl-contrib{MUMBLE}.jar on the filesystem by searching directories referenced on the class path. • Replacing the occurance of 'abcl' with 'abcl-contrib' in the the name of the system jar pathname, and then introspecting the contents. It would probably be helpful to add the following strategies to find members of ABCL-CONTRIB: • Locating an abcl-contrib.asd artifact via the usual ASDF conventions. • Retrieving the contents of ABCL-CONTRIB from the network via a "cool URI". • (Java 11) Appropiate use of Java modules to describe graphs of loadable ABCL artifacts. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Woohoo! What will it take to get JSS working? thanks, Cyrus On 3/8/19 12:54 PM, Mark Evenson wrote:
It turns out that if we pretend that Java 9 and Java 10 never existed, we can run a lightly modified version of [ABCL on Java11][11].
Once I get something stable, that mostly works across both openjdk8 and openjdk11, I think I would like to fork an abcl-2.0.0 while maintaining support for openjdk[678] via the abcl-1.m.n series,
Our CL:PATHNAME stuff needs to be adapted because Java11 stops referring to classes in `jar:file` location in favor of a synthetic reference to a `jrt:` path, but I think I may be able to easuly paper over this problem by tightening the isomorphism between a URI and the namestrings for ABCL’s implementation.
[11]: https://github.com/armedbear/abcl/pull/96
Surprisingly, the compiler seems to work fine, so the implementation is certainly not intolerably slow under Java 11. JSS certainly does not work but the ABCL-CONTRIB works for implementations with access to a filesystem on which CL:DIRECTORY can work.
This patch reworks ABCL-CONTRIB strategy to introspect the value of the the Java system property "java.class.path". This may not be sufficient to find the contribs under all possible ways that the implementation may be hosted.
To provide some background to the issues here, ABCL-CONTRIB is deliberately packaged separately from the contents of abcl.jar in order to:
• Keep the base ANSI implementation plus the included ASDF version in a single artifact with no other dependencies.
• Push the decision to potentially infringe on licenses explicitly to the user.
The knowledgable User may use the build-time option for the inclusion of code in system.lisp and the AIO packaging mechanism to create an unified "All-in-one" artifact.
Since ASDF is always included as part of the base abcl.jar, we may rely on its presence to find additional artifacts to add as additional code to abcl, aka. "the abcl contribs". Currently, this is achieved by the following strategies, tried sequentially until one is found to be successful:
• Introspecting for an implementation of "org.abcl-contrib" as declared in the system jar manifest.
• Attempting to locate a jar file named abcl-contrib{MUMBLE}.jar on the filesystem by searching directories referenced on the class path.
• Replacing the occurance of 'abcl' with 'abcl-contrib' in the the name of the system jar pathname, and then introspecting the contents.
It would probably be helpful to add the following strategies to find members of ABCL-CONTRIB:
• Locating an abcl-contrib.asd artifact via the usual ASDF conventions.
• Retrieving the contents of ABCL-CONTRIB from the network via a "cool URI".
• (Java 11) Appropiate use of Java modules to describe graphs of loadable ABCL artifacts.
Sent from my iPad
On 08.03.2019, at 21:59, Cyrus Harmon <ch-lisp@bobobeach.com> wrote:
Woohoo! What will it take to get JSS working?
Not too much, I hope. I figured out how to enumerate all potentially loadable classes without reference to jar archives today, which is the first step towards getting the SHARPSIGN_HASH macro working. And I am in communication with Alan Ruttenberg, who should be invaluable in getting JSS working. Stay tuned, Bear fans…
Since this thread mentioned JSS, I would like to use the opportunity to understand it better. Is JSS the best approach for making a Lisp wrapper around a Java library? I know that we had the previous project related to RDF and ABCL, building wrappers around the http://jena.apache.org/, but all initiatives that I know are not active anymore. I was trying to learn the best approach to use nowadays. Best, -- Alexandre Rademaker http://arademaker.github.io
On 8 Mar 2019, at 17:59, Cyrus Harmon <ch-lisp@bobobeach.com> wrote:
Woohoo! What will it take to get JSS working?
thanks,
Cyrus
On Mar 9, 2019, at 01:37, Alexandre Rademaker <arademaker@gmail.com> wrote:
Since this thread mentioned JSS, I would like to use the opportunity to understand it better. Is JSS the best approach for making a Lisp wrapper around a Java library? I know that we had the previous project related to RDF and ABCL, building wrappers around the http://jena.apache.org/, but all initiatives that I know are not active anymore. I was trying to learn the best approach to use nowadays.
[JSS][] certainly remains a key part of integrating Java code into into ABCL, mainly because Alan Ruttenberg keeps adding features, and its users keep fixing bugs. But JSS is just part of [contributions we ship with ABCL][abcl-contrib] that may be used in making Lisp wrappers of Java libraries. Of equal importance in ABCL-CONTRIB is probably [abcl-asdf][], which allows one to refer to the installation of Java libraries from the distributed network of Maven annotations. In the “project related to RDF and ABCL” (i.e. Jeannie), it is this ability to refer to the [Jena artifacts in the ASDF definition][jeannie] that is probably more useful than JSS itself, as it “automates” the steps that the end user needs to perform to install the Java libraries that one is wrapping. Note Jeannie is probably still as active a project as it has ever been, in that I still ensure that Jeannie works for my usage, updating the Jena artifacts when I have the need. For a more groovy experience in interactively working with Java code, there exists [a substantial re-working of SLIME with abcl-1.5.0][slime/abcl]. Work on [merging these patches with mainline SLIME][slime/pull/502] constitutes on ongoing project. [JSS]: https://gitlab.common-lisp.net/abcl/abcl/blob/master/contrib/jss/README.mark... [jeannie]: https://bitbucket.org/easye/jeannie/src/94292eee81d53046d9844e5e6c31cf76811726e9/jeannie.asd?at=default&fileviewer=file-view-default [slime/abcl]: https://github.com/easye/slime/tree/abcl [abcl-contrib]: https://gitlab.common-lisp.net/abcl/abcl/tree/master/contrib/ [abcl-asdf]: https://gitlab.common-lisp.net/abcl/abcl/tree/master/contrib/abcl-asdf [slime/pull/502]: https://github.com/slime/slime/pull/502 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
I am happy to announce that I have now managed to get JSS and the rest of ABCL-CONTRIB [working under Java 11][1]. [1]: https://github.com/easye/abcl/tree/jdk11 In the end, the total amount of changes needed was actually quite small. The current changes almost entirely stem from move in Java11 to use the new module system for all system artifacts in that they are no longer distributed in jar archives, but instead use a new URI scheme of ‘jrt’ (presumably an abbreviation for “Java runtime”). Combined with anecdotal evidence that the adoption of Java11 is proceeding quite a bit slower than ORCL had perhaps hoped, I no longer think that forking the ABCL codebase into two versions supporting pre and post Java11 makes that much sense at this time. Instead, I think I will clean up the current patch, commit to the main repository, and prepare an abcl-1.6.0 release that will support Java 6, 7, 8, and 11, skipping Java 9 and 10, which are EOLd at this point anyways. Comments and experience with the patches are welcome as always. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
participants (4)
-
Alexandre Rademaker -
Cyrus Harmon -
evenson -
Mark Evenson