The Bear Arms for Sharing Byte Vectors with 1.7.0

We are pleased to announce the immediate availability 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.

Now, the :NIO-BUFFER keyword argument to CL:MAKE-ARRAY 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 measurable gain in program performance. In the near
future, we intend to explore 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 for each component they
contain.  With a memory mapped direct buffer we should be able to
simply read from the appropriate byte offset for each component.

A complete overview of the accumulated fixes and changes since the
previous release may be viewed in the file describing our CHANGES.

ABCL 1.6.1 Springs Forth

As augured, the Bear is pleased to join fellow open ANSI Common Lisp implementations CCL, ECL, and SBCL in publishing a new release around the online advent of the thirteenth European Lisp Symposium, ELS2020.

The ABCL 1.6.1 binaries and signatures are now available with their associated CHANGES.

Thanks to everyone involved in continuing to further the progress of our implementation.

ABCL-1.6.1 at ELSCONF

Rejoice! for the Bear has emerged from its Lair to slough off abcl.1.6.1 Please see CHANGES for a summary of improvements over the previous release.

Please get any outstanding patches in before April 27, 2020 as we will be releasing abcl-1.6.1 live "at" #ELSCONF.

Currently, the release candidate rc-0 has been committed to various cloud builds; we will be rendezvousing with the cryptographic signatures to do the actual public release on Monday. ABCL-BUILD doesn't have reproducible builds, but we're actively working on fixing that…

stay tuned until Monday Bear fans,

Stuffing an @Armedbear

Notes on stuffing the Bear into a single jar with ABCL-AIO after T-day for Black Friday.

Happy Thanksgiving!

Unleashing the Bear past Java 11

Against the falling canvas of 2019, the Bear has freely thrust ABCL
1.6.0 onto the world stage.

This release fully supports building and running on Java 6, 7, 8, and
11 via the openjdk runtimes.  By building from our
source, it is rumored that the User may utilize additional
hosting platforms such as Java 13.

Support for Microsoft Windows platforms has not been thoroughly tested
at this point but we intend to add it our automated cloud based build
in the process of releasing a stabilizing ABCL 1.6.1 build due by the
end of this year.

Thanks to all past, present, and future contributors to the Bear;
here's to hackin' our way out of the prison of the Java
language for over a decade.

Turning the Bear past Java 11

As the leaves fall in the Northern hemisphere, thoughts of the Bear
turn to a rumored permanent slumber, and a complete absence of the
possibility of new updates.  The Bear reviews all submitted
patches, so if you don't like the current implementation,
please get out and push.  Or pull?  Or fast forward? The Bear is
seemingly always confused with Git…

As previously rumored, patches for getting the Armed Bear
Common Lisp implementation running on Java 11 have landed in
the trunk.

Unless anyone objects strongly, we will release ABCL 1.6.0 as soon 
as possible with the intention to support the openjdk{6,7,8,11} runtimes.

After stabilizing the 1.6 branch with the inevitable necessary and
unknown updates, we can turn our attention to the ABCL 2.0 branch which
will introduce support for additional runtimes but drop support for emitting 
openjdk6 or openjdk7 compatible byte-code.

Stay tuned, Bear fans…

ABCL 1.5.0

We are pleased to announce that we have released the Sixth Edition of the Armed Bear Common Lisp implementation as ABCL 1.5.0.

Due to the lack of a publicly available Java 5 implementation, with this release we drop support for that platform, and henceforth support running on Java 6, Java 7, and Java 8. 

In addition to consolidating eight months of bug fixes, the following notable features are now also present in the implementation.

The compiler now records more complete debugging information on the SYS:SOURCE symbol property.

ABCL-INTROSPECT offers improved inspection of backtraces to the point that local variables may be inspected in Lisp debug frames.  Patches to SLIME to use this feature are in the process of being merged into the upstream repository. The OBJECTWEB system allows the user to disassemble JVM bytecode via dependencies managed by Maven.

JSS now contains a syntax for accessing Java static and member fields.

For declaring dependencies on Java artifacts ABCL-ASDF,  we have added an experimental syntax to address JRE/JDK artifacts via the ASDF:JDK-JAR class, as well as the ability to more finely control Maven dependencies with the  ASDF:MVN-MODULE class.

A complete list of changes may be viewed in the source repository.

Binaries for this release may either be downloaded directly from http://abcl.org/releases/1.5.0,  retrieved from the distributed Maven POM graph, or run from Docker via

    docker run -it easye/abcl:1.5.0

Many thanks to all who have contributed to nurturing the Bear's execution of conforming ANSI Common Lisp on the Java Virtual Machine.