CommandBox Docker v3.5.0 Images Released

Jon Clausen May 03, 2022

Spread the word

Jon Clausen

May 03, 2022

Spread the word

Share your thoughts

CommandBox 3.5.0 Docker images released

Today we are pleased to announce the release of version 3.5.0 of our CommandBox Docker images, which contains significant upgrades to the underlying CommandBox engine.

Most significantly, this release upgrades the CommandBox binary to 5.5.1, which uses Lucee 5.3.9 as the underlying CFML engine. In addition, this release changes the underlying base image over to use the eclipse-temurin image builds, as the adoptopenjdk builds are being sunsetted. With this change, the underlying Debian version changes to use Ubuntu 20.0.0 (focal). As such, some custom installs in Dockerfiles may need updates to available packages from this distro.

In addition, we have added linux/arm/v7 as an available architecture, for 32-bit systems. Alpine images continue to be available in only amd64 at this time.

Changelog for this version - versions denote `[CommandBox binary version ]/[ image version ]:

[5.5.1/3.5.0] - 2022-05-03

Changed

Change base images to use the eclipse-temurin base images
Change Ubuntu version to 20.0.0 (focal)
JREs updated to jre-11.0.15
CommandBox binary updated to 5.5.1

Added

Added linux/arm/v7 to supported architectures for Debian-based images

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

The MatchBox open beta is live at https://boxlang.ortusbooks.com/boxlang-framework/matchbox, and it brings something genuinely new to the BoxLang ecosystem: a path into WebAssembly.

That means BoxLang code can now move into browser applications, static-site deployments, edge runtimes, and WASI-style containers - without requiring a JVM. The feature is still beta, but the core direction is already useful: write BoxLang, compile it with MatchBox, and ship the generated WASM artifact to wherever a small portable runtime makes sense.

BoxLang 1.14.0 : Introducing Inner Classes

BoxLang has always embraced a simple truth: the way you organize code shapes the way you think about problems. For a long time, if you needed a helper class, you needed a file. One class, one .bx file, no exceptions. That's clean and predictable, but it creates real friction when a class is tightly coupled to exactly one caller and has no business existing anywhere else.

Blog