Greetings Armed Bear fans,

Since, I've been able to get our favorite Bear to run on [openjdk15][6], which has now replaced openjdk14 in our CI test regime, an update is in order about the release schedule of [ABCL 2.0][3] for those of you following along at home, and let’s face it: only the homeless aren’t at home these days.

** Either abcl-1.8.0, or abcl-2.0.0 or both will be released by 10.10.2020 **

[abcl-1.8.0][1] will be the last release support openjdk6 and openjdk7 runtimes. [abcl-2.0.0][2] will require openjdk8, and will run on openjdk11, openjdk13, openjdk14, and openjdk15.

We will fix compatibility with previous versions of the implementation by incompletely and inefficiently re-implement the use of CL:PATHNAME-DEVICE to "paper over” the use of nested jar references. The ability to access nested jar entries via CL:PATHNAME references has been broken since the openjdk support for nested references to jar files dropped for their creation. Nobody seemed to notice this problem, accept for customers of the [ASDF-JAR][4] contrib which is currently unable to load classes

Since either openjdk5 or openjdk6, references like

#p"jar:jar:file:/var/tmp/cl-ppcre-2.1.1.jar!/cl-ppcre/packages.abcl!/__loader__._”

while syntactically valid cannot actually address the contents on zip files withing zip files.

Since we would like such nested jar entries for use by strategies like ABCL All-in-Once (AiO), with [abcl-1.8.0][2] will allow an arbitrary PATHNAME-DEVICE component designating a sequence of nested archive entries. With openjdk8, we can use abstractions to make the caching efficient, but the current strategy (will) just reference everything by a weak reference to allow the implementation to garbage collect if it finds itself under memory pressure. In an era of the available of cheap gibibyte heaps, potentially retaining references to the bytes of artifacts accessed via CL:LOAD will be a viable strategy for at least the core implementation which is only ~ 11 mebibyte.

ABCL-2.0.0 will use all of the ABCL-1.8.0 code in additional to an implementation of multi-threaded sensitive atomic operations supporting ubiquitous contemporary ANSI CL compare and swap for memory.

The presence of a new compiler for ABCL-2.0.0 is no longer a release driver as it currently stands, but I would love some help if it shows up. Once I get things working well under openjdk8, I will start to work on the new compiler infrastructure.

Comments, patches, criticisms welcome!

yours, Mark

[1]: https://github.com/armedbear/abcl/blob/05e4b396658d7ba4bd074a8e4f627deec3b7989d/doc/design/pathnames/abcl-pathname.org [2]: https://abcl.org/trac/milestone/1.8.0 [3]: https://abcl.org/trac/milestone/2.0.0 [4]: https://gitlab.common-lisp.net/abcl/abcl/-/blob/master/contrib/abcl-asdf/README.markdown [5]: https://gitlab.common-lisp.net/abcl/abcl/-/commit/0ba7dea278a474efe0a8e7550c3947dea93feb33 [6]: https://travis-ci.org/github/armedbear/abcl/jobs/728128870