This release is now available on the develop branch.
Use :jvm-develop and :native-develop tags to test it.
This release changes virtually no functionality.
It refactors the entire build and deprecates the native image.
Reasoning
It pains me to deprecate native image builds, especially when we are able to see builds run on 70-100MB of RAM.
However, with the advancements of Project Leyden, Janitorr can now run in a JVM and use less than 200MB of total RAM.
Expecting users to dedicate about that much memory to a useful application running 24/7 is something that I feel I am able to justify.
But why? Native image has been the recommended way to use Janitorr for nearly 2 years.
As I went through the trouble of making it work, I felt that everyone should use it. From a user perspective, there were really no downsides to it.
However, the downsides are definitely felt during development. Native image requires a lot of workarounds and boilerplate, just to get it running. Its build times are in the minutes, even on my development machines that have way stronger CPUs than anything running in the GitLab runners. This wouldn't be a problem if I could develop in a JVM - but there's always the extra step of validating the native image after development is long finished to make sure I am not missing special settings that need to be enabled.
Additionally, usage of libraries for persistence or even a frontend was held back by this too. These are still not things I want for Janitorr as of right now, but I simply could not have added them in such a way that they were compatible with native image.
I also have to patch an integral class of the JDK I use to build the native image with my own implementation, only to get file system encoding to work correctly.
Conclusion
All that being said, I'm incredibly proud to have supported it for as long as I did. This has been one of the very few open source Spring (Boot) projects running native image AND pure Kotlin, finding solutions for (long standing) bugs and being on the bleeding edge of what the Java eco system has to offer.
All of these workarounds and hacks won't be necessary anymore and I'm opening up Janitorr to new development (and potentially developers submitting PRs).
Future
For a 2.0 release of Janitorr, I would like to add some new (or requested) features. I think supporting notifications of some sort does make sense. I am still not fond of adding a persistence layer though - so we shall see.
However, 2.0 will remove native image entirely, if not earlier.
I am going to experiment with AOT as well. Right now, AOT requires workarounds and boilerplate, but not to the same extent that native image does, because classes can still be loaded dynamically and reflection continues to be available at runtime.
Ideally, I'd like to keep AOT and Leyden working together. I will have to weigh the amount of boilerplate code required against the memory savings and may rid myself of it entirely. Nothing is set in stone.
If it becomes necessary to reduce memory consumption even further, I'll take a look at reducing the memory used by the JVM itself, possibly via custom builds of Hotspot.
Lastly: I am confident this is the right step.