GUI wrapper for jextract

[Sundararajan Athijegannathan]

Binary download of jextract does not include org.openjdk.jextract.jmod file (although that is part of jextract build folder).

For now, you can workaround using the following:



$ cat Main.java

import org.openjdk.jextract.*;

import java.awt.*;


class Main {

  public static void main(String[] a) {

    System.out.println(Frame.class);

    System.out.println(JextractTool.class);

  }

}


# assume that the current directory is "bin" dir of

# jextract tool. It has a javac executable in it.

# We use jextract's javac but pass module-path for the

# other jdk modules not included in jextract jdk image.


$ ./javac --module-path /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods --add-modules java.desktop --enable-preview --source 19  Main.java


If you're okay with building jextract from the sources, then you use JDK 19's javac with the following option:

--module-path $JEXTRACT_REPO/build/jmods


[That directory $JEXTRACT_REPO/build/jmods contains org.openjdk.jextract.jmod module file]


-Sundar
________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir Lisker <nlisker at gmail.com>
Sent: 06 October 2022 07:51
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: Re: GUI wrapper for jextract

Yes, if I can interface with the tool directly it would be ideal.

How can I add jextract as an external dependency for this? The jextract build is not a full jdk, and I'm running on jdk-19.

On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>> wrote:

Hi Nir,

On 02/10/2022 22:31, Nir Lisker wrote:
5. When analyzing the symbols of a header using the dump option, I need to read the file that jextract creates from disk and then delete it. Is there a way to read the jextract output directly? Either through the output stream, or writing to a file in memory? Dealing with disk I/O is cumbersome, comes with permission restrictions, and might be slow if done for many files in a batch.

I think ultimately, working with files might be not ideal for your use case.

There is a pseudo-stable API to parse jextract files, in the JextractTool class (in the org.openjdk.jextract package, which should be exported by the jextract module):

`public static Declaration.Scoped parse(List<Path> headers, String... parserOptions) {`

We do not make any promise (at this stage at least) on the stability of the API. That said, it has not changed much (at all?) in the last couple of years.

What you get back is a "Declaration", which is used to model vars, structs, unions, typedefs, functions

Then, attached to declarations, there are "Type"s, which are used... well, to model types. Since some type can be structured (e.g. a struct type), they can point back to their declaration (e.g. Type.Declared).

Jextract does all it does by defining visitors on this basic declaration tree, which is obtained by wrapping the results of parsing a C header using the clang API (e.g. clang Cursors).

We did this to "sanitize" the output of clang, as well as to make our implementation more robust and less dependent from clang internals.

One option for you would be to invoke the parsing process this way, then get the tree and look at the results (e.g. with a visitor), which sounds better than parsing an option file.

Cheers
Maurizio


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221006/35e8b71b/attachment-0001.htm>