Re: ABCL starting to work under Java11

Cyrus Harmon <[email protected]>
Newsgroups gmane.editors.j.devel
Message-ID <7ed55739-8005-5ac9-8034-59245e7a5efe__18386.5546876163$1552079335$gmane$org@bobobeach.com>
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.
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.