Hi,
Hi,
thanks for your answer.
The indexing part would be part of the build time if I understood it well.
On embedded platforms I would just want to use the index files for faster JVM-based access during startup-time (not especially GraalVM).
That is how Jandex is typically used, even WildFly supports that.
I've also read that maybe Java 17 is considered. That would be also a target for embedded platforms but the most still run on Java 8.
Jandex is still a Java 8 project. I'm intentionally conservative here and don't plan to bump to a newer Java version anytime soon.
Is there a documentation available for the index file itself?
No. The format is not documented, although the reader/writer classes in the codebase make the structure of the format fairly clear. I wouldn't recommend reimplementing it, though, because it can change at any time (recently, I've been thinking about creating a V3 format that would no longer need versioning, because versioning has been a constant hassle; no specific design or code yet).
Maybe I can create a small Java 8 compliant client API (maybe keeping compliant to the API of Jandex itself) which just uses the index files.
I've the feeling that such a client API could be < 100 KB.
I feel like if you drop only the indexing part, you'll only be able to drop `Indexer` and `IndexWriter`. Those are pretty big classes, but I doubt they themselves consist of 300 kBs. So to be able to get to < 100 kBs, you'd have to remove some parts of the API as well. That would of course be possible (I've recently added APIs that might be useless to you, such as `EquivalenceKey` and `AnnotationOverlay`), but at that point, I feel like you're creating a whole new project.
I personally don't think that Jandex is a big project, but I also readily admit that JAR size has never been a concern to me -- unlike memory footprint and to a degree also raw speed.
LT
Background: I'm currently planning and developing a platform for embedded devices similar to Spring and Quarkus but with focus on the requirements and security issues for embedded devices.