-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
repo-panama
The jextract tool is currently very hard to configure; the behavior can vary significantly, depending on factors that will not be perceived as important to the user, such as whether an included header is in a path that share some prefix with some of the headers appearing in the command line.
When some of these obscure criteria is not met, jextract will generate broken artifacts, with dangling references.
Moreover, jextract currently generates one header class per header file. This policy is wrong, as there should be an artifact per _library_ (and the library classes should be self-contained).
After some thinking, and looking at some common use cases, we believe that a strategy like the one described below could work:
1) parse root declarations; roots can be of two kind:
a) declarations in headers specified in the command line
b) declarations in some other header which is (1) included from a command line header and (2) in the same folder as one of the command line headers
2) from here, keep adding declarations on a by-need basis - e.g. if a declaration in the root set references to something outside the set, add that to the root set
3) repeat (2) until root set is stable
4) we can finally generate a single HeaderTree with all the declarations in it; there will be one declaration per element in the root set; structs and ancillary definitions will end up in separate classfiles.
5) (optional) Name conflicts should be resolved (e.g. as javac makes up unambiguous names for inner classes); alternatively, the user can map declarations from headers in different paths in classfiles in different packages (~= -m)
With this approach, jextract will always generate what is needed to support a given library. The only failure mode that can arise from this is if some header file cannot be resolved, in which case that means some include path must be set manually.
This scheme can also be extended to support multiple jextract runs: more specifically, step (2) can be enhanced to try and resolve dependencies in imported jars first (e.g. jextract-path).
When some of these obscure criteria is not met, jextract will generate broken artifacts, with dangling references.
Moreover, jextract currently generates one header class per header file. This policy is wrong, as there should be an artifact per _library_ (and the library classes should be self-contained).
After some thinking, and looking at some common use cases, we believe that a strategy like the one described below could work:
1) parse root declarations; roots can be of two kind:
a) declarations in headers specified in the command line
b) declarations in some other header which is (1) included from a command line header and (2) in the same folder as one of the command line headers
2) from here, keep adding declarations on a by-need basis - e.g. if a declaration in the root set references to something outside the set, add that to the root set
3) repeat (2) until root set is stable
4) we can finally generate a single HeaderTree with all the declarations in it; there will be one declaration per element in the root set; structs and ancillary definitions will end up in separate classfiles.
5) (optional) Name conflicts should be resolved (e.g. as javac makes up unambiguous names for inner classes); alternatively, the user can map declarations from headers in different paths in classfiles in different packages (~= -m)
With this approach, jextract will always generate what is needed to support a given library. The only failure mode that can arise from this is if some header file cannot be resolved, in which case that means some include path must be set manually.
This scheme can also be extended to support multiple jextract runs: more specifically, step (2) can be enhanced to try and resolve dependencies in imported jars first (e.g. jextract-path).
- relates to
-
JDK-8208199 Revisit one interface per header file approach
-
- Closed
-