RFR: 7903608: Cyclic initialization leads to NPE in header class with global variable [v2]
Maurizio Cimadamore
mcimadamore at openjdk.org
Thu Dec 14 14:59:16 UTC 2023
On Thu, 14 Dec 2023 13:27:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
>> src/main/java/org/openjdk/jextract/impl/ToplevelBuilder.java line 89:
>>
>>> 87: List<JavaFileObject> files = new ArrayList<>();
>>> 88:
>>> 89: if (headerBuilders.size() == 1) {
>>
>> The changes here are the trickiest. Basically, we can't figure out in advance which name header classes should have. So we end up generating something like:
>>
>>
>> <headerName>_h#{SUFFIX} extends {PREV_SUFFIX}
>>
>>
>> And then leave it to the code here to fixup all the suffixes. For this reason, the name of the runtime helper class cannot just be the current "class name" as that would include the `#{SUFFIX}` bit - but we know that there is going to be _some_ `<headerName>_h` generated at some point, so we can just use that as a runtime helper name.
>>
>> Overall, I'm not too proud of this code, but at the same time, after evaluating a couple of alternatives they all seemed too complicated. And, we were doing some magic name adaptation even before.
>
>> but we know that there is going to be some <headerName>_h generated at some point, so we can just use that as a runtime helper name.
>
> So, just to clarify: we use the last header class we generate as the runtime helper (having no name suffix), but the runtime helper methods and primitive layouts are actually in the first header, and they are visible through static inheritance?
yes, the last (deepest in the inheritance tree) is used as the runtime helper. That is also the public header class that users depend on. The helper methods are not here, but they are accessible anyway because of inheritance, so it works out.
-------------
PR Review Comment: https://git.openjdk.org/jextract/pull/160#discussion_r1426833291
More information about the jextract-dev
mailing list