ABCL-1.7.0 released

Gregory Baryza gabaryza at
Thu Jun 4 16:57:32 UTC 2020

As released, this will not compile using Java 14.

File:, line 13, needs to be changed from




File src/org/armedbear/lisp/java/swing/, line 144, needs to
be changed from




because the compiler reports that the command "yield" is now a reserved
word. Adding the class name makes it clear this is a function reference.

I apologize for not checking these in, but there are other reasons for my
not becoming a member of the dev group.

G.A. Baryza

On Thu, Jun 4, 2020 at 6:31 AM Alessio Stalla <alessiostalla at>

> Congrats!
> On Thu, 4 Jun 2020 at 12:28, Mark Evenson <evenson at> wrote:
>> We are pleased to announce the immediate availablity of the [ABCL
>> 1.7.0 release][].
>> After consuming a steady diet of java.nio.ByteBuffer objects over the
>> past month, the Bear has managed to incorporate the use of these
>> abstractions for arrays specialized on the commonly used unsigned-byte
>> types (or (unsigned-byte 8) (unsigned-byte 16) (unsigned-byte 32)).
>> This replacement of the use arrays of primitive bytes is denoted by
>> the presence of the :NIO keyword in CL:*FEATURES*.
>> With this :NIO overhaul, we have extended our implementation of ANSI
>> Common Lisp [CL:MAKE-ARRAY][] with two additional keywords,
>> viz. :NIO-BUFFER and :NIO-DIRECT.
>> The :NIO-BUFFER keyword argument allows one to construct a vector
>> directly utilizing the contents of an already allocated
>> java.nio.ByteBuffer object.  When combined with the ability of JNA to
>> allocate memory on the heap via a malloc() system call, we implemented
>> shareable byte vectors in [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR][].
>>     (let* ((length 16)
>>            (byte-buffer (java:jstatic "allocate"
>>                                       "java.nio.ByteBuffer" length)))
>>       (make-array length :element-type ’(unsigned-byte 8)
>>                          :nio-buffer byte-buffer))
>> When the :NIO-DIRECT keyword argument is called with a non-NIL value,
>> the implementation creates a byte vector with a "directly allocated"
>> java.nio.ByteBuffer object.  Such direct buffers typically have
>> somewhat higher allocation and deallocation costs than non-direct
>> buffers.  The contents of direct buffers may reside outside of the
>> normal garbage-collected heap, and so their impact upon the memory
>> footprint of an application might not be obvious. It is therefore
>> recommended that direct buffers be allocated primarily for large,
>> long-lived buffers that are subject to the underlying system’s native
>> I/O operations.  In general it is best to allocate direct buffers only
>> when they yield a measureable gain in program performance. In the near
>> future, we intend to exploring the performance gains available CL:LOAD
>> by accessing direct buffers memory mapped to our on-disk fasl
>> representation.  Our fasls, as zipped archives, currently require a
>> new seek() from the beginning of the fasl for each component they
>> contain.  With a memory mapped direct buffer we should be able to
>> simply read from the appropiate byte offset for each component.
>> A complete overview of the accumulated fixes and changes since the
>> previous release may be viewed in [CHANGES][].
>> [ABCL 1.7.0 release]:
>> [java.nio.ByteBuffer]:
>> --
>> "A screaming comes across the sky.  It has happened before but there is
>> nothing
>> to compare to it now."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the armedbear-devel mailing list