A brand new day brings a brand new release: I'm ecstatic to announce that Layrry 1.0.0.Alpha1 has been released!
You can find all artifacts at Maven Central, Bintray, download them from Layrry's releases page, or build it yourself by cloning https://github.com/moditect/layrry.git and following the build instructions found in the README, basically mvn install (yup, install is needed in this case, you can skip the clean). What's more, you can also install Layrry directly from SDKMAN! as it's now available as a candidate.
🤩😱😍🥳 #Layrry at @sdkman_ pic.twitter.com/Kgu1BrsCaO
— Andres Almiray (@aalmiray) January 30, 2021
What's all the fuzz about Layrry anyway? Well to put it mildly it may be the best thing that has happened to the Java Platform Module System since it was released in Java 9. As you may know Java Platform Module System enables new design capabilities around Java modules, giving you more control over APIs that should be exposed to the public vs. those that must remain private (such as implementation details). Module references are used at compile time to verify that all dependences (required modules) are available; otherwise a compilation failure will occur. Modules can also be used to create personalized Java Runtime images using the jlink tool.
While these and other features provided by the Java Platform Module System prove to be quite helpful there are a set of scenarios that it does not support out of the box. However it provides the building blocks (such as ModuleLayer) that allow third parties to deliver said features. This is where Layrry comes in.
Layrry provides the following features on top of Java Platform Module System:
- Ability to use multiple (potentially incompatible) versions of a dependence by isolating them in different module layers
- Module resolution via Maven coordinates
- Remote/local/offline module resolution
- Module versioning support
- Dynamic class loading/unloading
- Local/remote external config via YAML/TOML
- Parameterized config
- JFR integration
Layrry enforces “just enough isolation” between your modules thanks to the ModuleLayer API. Unlike other module systems which employ one classloader per module, Layrry lets you put multiple modules into one layer and thus load them with a single classloader. This makes the Layrry approach much easier to adopt, in particular when considering existing external libraries, while still benefiting from classloader isolation between layers, where it makes sense. It’s worth mentioning that modules may be defined as full modules (using a module descriptor, i.e, module-info.class) or as automatic modules (using the Automatic-Module-Name JAR manifest entry).
In the following video Gunnar Morling (@gunnarmorling, Layrry's creator) and myself explain the reasoning behind Layrry, most of its features, and where it could be headed in the future.
The sample JavaFX application can be downloaded from https://github.com/moditect/layrry-examples/. This repository includes a few more examples that demonstrate Layrry's capabilities. We're quite excited by how Layrry has shaped up so far and we look forward to what you can build with Layrry. Should you encounter any issues with Layrry, have an idea for a neat feature, or any other kind of feedback do let us know, Layrry's issue tracker is located at https://github.com/moditect/layrry/issues.
Keep on coding!
Image by Dan Fador from Pixabay
