[jnigen] generates invalid generic JType wrappers for JList and JMap that breaks compilation

[tarrinneal]

Starting with jnigen (0.16.0-wip versions onwards), when generating Dart bindings for Java/Kotlin methods that return generic collections like java.util.List or java.util.Map, jnigen generates statically invalid strict type mappings that fail Dart compilation.

Given a Kotlin method that returns a nullable List or Map format (such as from pigeon):

interface NIHostIntegrationCoreApi {
   fun echoList(list: List<Any?>?): List<Any?>?
   fun echoMap(map: Map<Any, Any>?): Map<Any, Any>?
}

jnigen generates the following JObject wrapper back into Dart:

  static final _id_echoList = NIHostIntegrationCoreApi._class.instanceMethodId(
    r'echoList',
    r'(Ljava/util/List;)Ljava/util/List;',
  );

  jni$_.JList<jni$_.JObject?> echoList(
    jni$_.JList<jni$_.JObject?> list,
  ) {
    ...
    return $o.as<jni$_.JList<jni$_.JObject?>>(
      jni$_.JList.type,
      releaseOriginal: true,
    );
  }

When attempting to flutter build or run dart compilation against the generated bindings, compilation fails with the following errors for every JList and JMap usage:

Error: The argument type 'JType<JList<dynamic>>' can't be assigned to the parameter type 'JType<JList<JObject?>>'.
 - 'JType' is from 'package:jni/src/types.dart'.
 - 'JList' is from 'package:jni/src/core_bindings.dart'.
 - 'JObject' is from 'package:jni/src/jobject.dart'.
      jni$_.JList.type,
                 ^

Error: The argument type 'JType<JMap<dynamic, dynamic>>' can't be assigned to the parameter type 'JType<JMap<JObject?, JObject?>>'.
      jni$_.JMap.type,
                 ^

[tarrinneal]

here's gemini's take:

Reasoning & Root Cause: In package:jni, JList.type and JMap.type are defined generically as JType<JList<dynamic>> and JType<JMap<dynamic, dynamic>> respectively. However, the inline generated call $o.as<T>(JType<T> type) demands strict type alignment, meaning the type parameter must strictly be JType<JList<JObject?>>.

Because jnigen supplies the unparameterized .type field directly statically (rather than composing the nested type structure by nesting the inner generics or performing an explicit cast e.g., jni$_.JList.type as jni$_.JType<jni$_.JList<jni$_.JObject?>>), it creates physically un-compilable generated files.

Proposed Resolution: jnigen's generation logic needs to be updated to either:

Supply parameterized JTypes correctly (e.g. JList.type(JObject.type)) if supported by jni primitives, OR
Emit explicit downcasts as JType<...> to safely convert the raw .type fields so the generated code can still compile under standard Dart rules.

Note: I have not validated anything it says here, it may be entirely incorrect.

It's also possible that this issue has something to do with my local build settings, but I've tried everything I know and it hasn't resolved.

[liamappelbe]

Weird. This case is definitely covered by my tests. The error makes sense though, so I'm not sure why I haven't hit it yet. Does dart analyze pick up the issue, or only compilation? Is "strict type mappings" a build setting I need to enable?

It's mainly a limitation of Dart. What I want to do is jni$_.JList<T>.type, and get a JType<JList<T>>, but static members like type can't reference type params. It's because the static member is shared between all JLists. Unlike C++ you don't get a different static member for JList<JObject> vs JList<JString>. So it makes sense type can't reference T, but it's annoying.

The type params aren't actually needed by any JTypes anymore except for JArray, which is a special case anyway. So I can probably just make them all pass JObject? as the type params, when defining type. It's an easy fix, but I need to figure out why I'm not seeing this error first.

[tarrinneal]

Do you know what kotlin version you're running? I don't see it in the gradle files.

looks like you're on kotlin 1.8.10, I'm 2.1.0. Might not matter...

looks like adding an as [type] fixes the compilation errors. I have tests failing, but I think it's unrelated.

[liamappelbe]

Good to know. Do you see the errors when you run dart analyze though, or only during flutter compilation? I'm not sure how to repro/test this issue atm.

[tarrinneal]

only compilation

[liamappelbe]

That's annoying. Might need some new test infra then. Though I'm still kinda surprised that the android integration tests didn't catch this. You mentioned "statically invalid strict type mappings". Is that a build setting I need to enable?

[tarrinneal]

You mentioned "statically invalid strict type mappings". Is that a build setting I need to enable?

I actually don't know, maybe @stuartmorgan-g does?

[stuartmorgan-g]

This may be strict-casts from https://github.com/flutter/packages/blob/b2e421bc176c488730567e4edbdee6ed48d00473/analysis_options.yaml#L9-L12