The road to ABCL 2.0.0

[Mark Evenson]

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>





-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."