This month we’re lifting up the hood to report on some upgrades to the Kill Bill tech stack. While Kill Bill was not affected by the log4j vulnerability revealed in December 2021 (KB relies on slf4j and logback as an implementation), the log4j incident is a reminder to us all to stay up-to-date on the latest security patches and technologies.
The upgrades covered below will be implemented in our next release. You can see all of our releases here.
Upgrading to OSGi 8.0.0
One aspect of upgrading the tech stack has been working on upgrading the OSGi specification from 5.0.0 to 8.0.0, which will apply in our upcoming Kill Bill release (0.23.x).
Kill Bill plugins are created based on the OSGi specification, which provides a way to write isolated code on top of the Kill Bill platform and interact with the system. The purpose of OSGI-based plugins is to ensure that the plugins are isolated from each other and from the core platform. It lets Kill Bill users extend the system with minimal knowledge about the system.
As part of the OSGi upgrade, Kill Bill will support Java 17 (more on this in the next section). This means that users can develop their custom plugins per the latest specification and make use of new Java features added through Java 17. For more information on OSGi and Kill Bill plugins, see the Plugin Development Guide.
If you’d like to see what has changed in the OSGi standards, use these OSGi links:
Note that the OSGi specifications are backward-compatible to all prior releases, so this release should have no effect on Kill Bill systems running custom plugins. However, Kill Bill is a platform for building billing systems; there are lots of combinations of configurations possible, and we cannot test them all.
Support for Java 17
As mentioned above, our next release of Kill Bill will support Java 11 through 17. (Our current version only supports Java 8.)
Java 17 is Oracle’s latest version (though they’ll release a new one in late March 2022), and it’s a long-term support (LTS) release. This is important because we want you (as a Kill Bill user) to be able to take advantage of Oracle’s premium support if you want or need it.
One of the most important features released in Java 17 is that Java-based apps like Kill Bill can now run natively on the newer Arm 64-based Apple Silicon computers.
Replacing Our Runtime Code Generation Library
So, back to the tech stack upgrades. Internally, we’ve replaced our runtime code generation library. Up to this point, we had been using CGLib for many years.
However, CGLib did not keep up with the development of the Java platform, so we’ve replaced it with Byte Buddy. We believe this change will slightly improve the runtime performance of Kill Bill.
If you’re interested, check out this discussion of Byte Buddy from Oracle’s Java Magazine.
Kill Bill Has an Ongoing Commitment to Integrity
As you can see, maintaining Kill Bill isn’t just about adding new features; we’re dedicated to upholding its integrity.
Speaking of software integrity, open-source software like Kill Bill is becoming more widely accepted in enterprise organizations. Nowadays, it certainly helps to have DevOps software security tools from jFrog, Rapid7, and Snyx (there are many more). Enterprise organizations that are using Kill Bill find these apps indispensable in taking advantage of open-source software like Kill Bill while maintaining compliance and guarding against security flaws and threats.
Just thought we’d mention that in case you’re interested in using Kill Bill, but management has shied away from the idea. Software composition analysis (SCA) tools can get you to market and/or help launch your latest billing and payments system much faster, whether you’re using open-source software or the proprietary kind.
