ABCL starting to work under Java11

[Cyrus Harmon]

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