Skip to content

[jnigen] Config API update - #3516

Open
liamappelbe wants to merge 23 commits into
mainfrom
jnigen_api_update
Open

[jnigen] Config API update#3516
liamappelbe wants to merge 23 commits into
mainfrom
jnigen_api_update

Conversation

@liamappelbe

@liamappelbe liamappelbe commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Update JNIgen's config API to align it with the proposed FFIgen API.

  • Group classes, sourcePath, classPath, summarizerOptions, mavenDownloads, and androidSdkConfig into Input
  • Group import and hide into SymbolImports, which lives in Input.imports
  • OutputConfig renamed to Output, and still contains dartConfig -> dart and symbolsConfig -> symbols. Now also contains preamble, generateStubs, and format.
  • nonNullAnnotations and nullableAnnotations now grouped under NullabilityAnnotations.
  • Flip isExcluded to isIncluded.
  • Make a bunch of nullable fields non-null, if null is functionally identical to a default value.
  • For the fields where null is functionally different, document that. Also, document any other undocumented fields.

Sorry for the crazy number of changed files. It's mostly due to the version bump. There aren't any real bindings changes. Important files are:

#2062

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

Package publishing

If you have publishing permissions, you can use the links below to publish the changes after merging this PR.

Package Version Status Publish tag (post-merge)
package:code_assets 1.3.0-wip WIP (no publish necessary)
package:data_assets 0.20.0 already published at pub.dev
package:ffi 2.2.0 already published at pub.dev
package:hooks 2.2.0-wip WIP (no publish necessary)
package:hooks_runner 1.6.2-wip WIP (no publish necessary)
package:jni_flutter 1.0.2 already published at pub.dev
package:jni_util 1.0.0 already published at pub.dev
package:native_toolchain_c 0.19.4-wip WIP (no publish necessary)
package:record_use 1.1.0 ready to publish record_use-v1.1.0
package:swift2objc 0.3.0-wip WIP (no publish necessary)
package:swiftgen 0.1.3 already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

PR Health

Breaking changes ✔️
Package Change Current Version New Version Needed Version Looking good?
jni_flutter None 1.0.2 1.0.2 1.0.2 ✔️
jni None 1.0.3 1.0.3 1.0.3 ✔️

This check can be disabled by tagging the PR with skip-breaking-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package Leaked API symbol Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

@github-actions github-actions Bot added the type-infra A repository infrastructure change or enhancement label Aug 5, 2026
@liamappelbe liamappelbe changed the title WIP [jnigen] Config API update [jnigen] Config API update Aug 6, 2026
@liamappelbe
liamappelbe marked this pull request as ready for review August 6, 2026 04:58
@liamappelbe
liamappelbe requested review from dcharkes and goderbauer and removed request for goderbauer August 6, 2026 04:58
classes: ['com.github.dart_lang.jnigen.simple_package'],
sourcePath: [Uri.directory(sourcePath)],
input: Input(
classes: ['com.github.dart_lang.jnigen.simple_package'],

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Helicopter view level question: We can't put this as include on visitClass right? Because this goes into the summarizer which is a different stage in the pipeline.

I think the readme of both FFIgen and JNIgen would benefit from mermaid diagrams showing the pipeline and what in the config is configuring which part of the pipeline. (Feel free to file an issue to do this later. Mermaid diagrams are rendered on GitHub, I don't know about pub, and probably not in dartdoc either.)

Another super high level question, should options only passed to the summarizer be nested in the summarizer options? That might make it more clear for users.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the readme of both FFIgen and JNIgen would benefit from mermaid diagrams showing the pipeline and what in the config is configuring which part of the pipeline. (Feel free to file an issue to do this later. Mermaid diagrams are rendered on GitHub, I don't know about pub, and probably not in dartdoc either.)

Done #3527

Another super high level question, should options only passed to the summarizer be nested in the summarizer options? That might make it more clear for users.

Hmmm. Tricky question.

  • Most of Input's remaining fields are only passed to the summarizer. Even MavenDownloads and AndroidSdk populate sourcePath and classPath, which are passed to the summarizer. The only one that is completely separate is imports.
  • I don't necessarily want to advertise to users that the summarizer is a separate tool we run. There's a backlog bug somewhere to port the summarizer to Dart. In that case, extraArgs, workingDirectory, and maybe even backend could be deleted.
  • classes, sourcePath, and classPath are way more common than any of the options in SummarizerOptions.
  • Just realized that in the FFIgen config, importType is a top level member of the config object.

With all that in mind, maybe a better design is to move imports to be directly under Config, and then delete SummarizerOptions and flatten all its options directly into Input?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I don't necessarily want to advertise to users that the summarizer is a separate tool we run.

Hm, the fact that we have a summarizer puts a specific burden on the user right now, listing the class names.

There's a backlog bug somewhere to port the summarizer to Dart.

I would imagine we completely drop the list of classes then.

  • Just realized that in the FFIgen config, importType is a top level member of the config object.

The imports in FFIgen are for types that are generated by other FFIgen runs right? That "feels" more like a different source of information than the header files. I think conceptually the input relates to the parsing stage of the native code.

So I'd probably keep all the summarizer options in input then, since that's the parsing stage. Including the list fo classes.

And maybe importType should be nested in another config that indicates it is about importing already generated bindings generated by the same tool.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'd probably keep all the summarizer options in input then, since that's the parsing stage. Including the list fo classes.

Do you mean keep it as it is in 5c24777 with the 3 old fields in SummarizerOptions, as it is in 11ccc34 with everything in Input. Or do you mean move classes, sourcePath, and classPath into SummarizerOptions?

@dcharkes dcharkes Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think 11ccc34 looks slightly more natural to me. We don't explicitly call out the summarizer in the name but basically all of those fields relate to the parsing stage and are used with the summarizer.

But if you feel strongly about it, I don't have a strong opinion.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's the best approach too.

],
),
output: Output(
dart: DartCodeOutputConfig(

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't use dot shorthands to skip typing the constructor name can we?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you might be able to do dart: .new(? Personally I don't find that more readable.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, yeah I also find that not readable 😅

],
),
output: Output(
dart: DartCodeOutputConfig(

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We dropped Config suffix everywhere, this still has a config suffix.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed some others still have the config suffix as well, e.g. AndroidSdkConfig.

@liamappelbe
liamappelbe requested a review from dcharkes August 7, 2026 01:43

@goderbauer goderbauer left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants