While the current class-based generation is completely lazy and adds little overhead, there are cases (mainly revolving around Windows.h) where, even with this laziness, jextract ends up generating too many classes which are not used by the developer. Even if there's no initialization cost paid for all these classes, there's a considerable static footprint, coupled with overhead which is triggered by class loading (this seems to be unavoidable).

The only way out of these scenario would be for jextract to support some ways to filter out symbols. We have tried with many approaches in the past - from include lists, to include lists, to dependency-based analyses. None of these strategies seemed to be too convincing - they added a lot of command line footprint, and gave very little in return (other than to fix specific extraction use cases).

Similar tools seem to have ways in which users can describe "what" they want to extract, in several ways. For instance, in Rust's bindgen, there's an API (and set of command line options) which allow users to specify what needs to be filtered:

https://rust-lang.github.io/rust-bindgen/whitelisting.html
https://rust-lang.github.io/rust-bindgen/blacklisting.html

These are all built on top of the Rust's bindgen Builder abstraction:

https://docs.rs/bindgen/0.23.1/bindgen/struct.Builder.html

Or, as another example, in Kotlin we have a property file which is used to specify properties of the extraction process:

https://kotlinlang.org/docs/reference/native/c_interop.html

We should investigate the applicability of one of these strategies to jextract.