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.