[jni] Upgrade package:jni's ffigen

[HosseinYousefi]

Cherry-picked from #1884

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?
jni	Breaking	0.13.0	0.14.0-wip	0.14.0	✔️

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 symbols
jni	_ReferenceType _opaque_pthread_mutex_t _opaque_pthread_cond_t _Dart_FinalizableHandle

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

License Headers ✔️

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/jni/lib/src/third_party/generated_bindings.dart
pkgs/objective_c/lib/src/ns_input_stream.dart

[coveralls]

coverage: 87.372% (+0.002%) from 87.37%
when pulling b35df7c on upgrade-jni-ffigen
into fbeafe0 on main.

[dcharkes]

In the pub workspace, JNIgen will always depend on the same commit, so I believe it should be a path dependency. (And we should run some sanity check on the FFIgen workflow to see that we didn't break JNIgen.)

Thanks @HosseinYousefi! 🙏

[HosseinYousefi]

In the pub workspace, JNIgen will always depend on the same commit, so I believe it should be a path dependency.

I think I had jni as a path dev-dependency of jnigen (to use in tests) and @mosuem changed it to be a normal dependency (and added the jni path dependency as an override instead). I don't remember why this was needed but I wanted to tag him here as well.

[mosuem]

In the pub workspace, JNIgen will always depend on the same commit, so I believe it should be a path dependency.

I think I had jni as a path dev-dependency of jnigen (to use in tests) and @mosuem changed it to be a normal dependency (and added the jni path dependency as an override instead). I don't remember why this was needed but I wanted to tag him here as well.

Yes, this is so that people (or in the case which triggered that, tool) which get a package from pub.dev can run it. Otherwise it is not possible to compare the API of older packages to that of the current one, as the older versions will not compile. (Workarounds through git checkouts at certain tags might be possible, but ugly)

[HosseinYousefi]

In the pub workspace, JNIgen will always depend on the same commit, so I believe it should be a path dependency.

I think I had jni as a path dev-dependency of jnigen (to use in tests) and @mosuem changed it to be a normal dependency (and added the jni path dependency as an override instead). I don't remember why this was needed but I wanted to tag him here as well.

Yes, this is so that people (or in the case which triggered that, tool) which get a package from pub.dev can run it. Otherwise it is not possible to compare the API of older packages to that of the current one, as the older versions will not compile. (Workarounds through git checkouts at certain tags might be possible, but ugly)

A dev dependency should technically not stop compilation, however there are currently no way to only fetch deps (dart-lang/pub#2036)

Any tool could modify the pubspec to remove dev deps altogether before running though.

[mosuem]

Any tool could modify the pubspec to remove dev deps altogether before running though.

Or we can have a valid pubspec to begin with ;)

[HosseinYousefi]

Any tool could modify the pubspec to remove dev deps altogether before running though.

Or we can have a valid pubspec to begin with ;)

It IS a valid pubspec :) dev-deps will not be included in the runtime of the package.

[HosseinYousefi]

The failed test is not due to the current change. Merging...

[dcharkes]

In the pub workspace, JNIgen will always depend on the same commit, so I believe it should be a path dependency.

I think I had jni as a path dev-dependency of jnigen (to use in tests) and @mosuem changed it to be a normal dependency (and added the jni path dependency as an override instead). I don't remember why this was needed but I wanted to tag him here as well.

Yes, this is so that people (or in the case which triggered that, tool) which get a package from pub.dev can run it. Otherwise it is not possible to compare the API of older packages to that of the current one, as the older versions will not compile. (Workarounds through git checkouts at certain tags might be possible, but ugly)

Ah, when we flip to a pub workspace, this should actually be solved right. (We need to flip the path dependencies to published dependencies in the native_xxx packages as well in order to be able to publish. Then within the workspace it should work as a path dependency, but if you simply pub-get JNIgen you'd pull in the FFIgen from pub. So this is something we can only do once we actually convert this repo to a workspace. 👍