Skip to content

[jni] Add deep conversion utils #3143

Description

@liamappelbe

Copy the pattern from package:objective_c: https://github.com/dart-lang/native/blob/main/pkgs/objective_c/lib/src/converter.dart

In addition to the conversions provided by package:objective_c, we'll need converters for JArray and its variants.

Activity

  1. added this to the JNI / JNIgen EAP milestone on Feb 24, 2026
  2. added
    good first issueA good starting issue for contributors (issues with this label will appear in /contribute)
    and removed
    needs-triageNeeds triage from the team. Remove this label once triaged.
    on Feb 24, 2026
  3. deep4nsh commented on Feb 27, 2026

    @deep4nsh

    Hi 👋 I'd like to work on this issue.

    From my understanding, this involves adding utility functions
    for deep conversion in the JNI layer.

    Before I start, could you please confirm:

    • Which file or directory would be the appropriate place for this implementation?
    • Whether there are any existing utilities I should extend instead of creating new ones?

    Thanks!

  4. liamappelbe commented on Mar 2, 2026

    @liamappelbe
    ContributorAuthor

    This is a follow up to #3093, which hasn't landed yet. You'll need to wait for that.

  5. Siya-05 commented on Sep 11, 2026

    @Siya-05
    Contributor

    hey @liamappelbe, Can I work on this?

  6. liamappelbe commented on Sep 11, 2026

    @liamappelbe
    ContributorAuthor

    @Siya-05 sure. The APIs should match package:objective_c's conversion APIs as closely as possible.

  7. Siya-05 commented on Sep 13, 2026

    @Siya-05
    Contributor

    @liamappelbe, Since Java null references are represented as null/JObject?, should the JNI conversion API mirror package:objective_c with separate toDartObject(JObject) and toNullableDartObject(JObject?) functions, or should toDartObject itself accept JObject? and handle null?

    This also affects deep collection conversion, since JList, JSet, JMap, and JArray can contain nullable JObject? elements/keys/values. Should those converters preserve null recursively as Dart null?

  8. liamappelbe commented on Sep 14, 2026

    @liamappelbe
    ContributorAuthor

    Since Java null references are represented as null/JObject?, should the JNI conversion API mirror package:objective_c with separate toDartObject(JObject) and toNullableDartObject(JObject?) functions, or should toDartObject itself accept JObject? and handle null?

    Yeah, copy package:objective_c's approach here.

    This also affects deep collection conversion, since JList, JSet, JMap, and JArray can contain nullable JObject? elements/keys/values. Should those converters preserve null recursively as Dart null?

    I think this bit will diverge a bit from ObjC land. Java's null safety is generally very weak. Whereas in ObjC, collections cannot contain null (they have a special NSNull object instead).

    ObjC's generics are also a bit weaker than Java's, and much weaker than Dart's. Our Dart ObjC wrappers don't support generics at all.

    I see 2 options:

    1. Return JList<JObject?>, and let the user use .cast() to convert to whatever type they want.
    2. Make the conversion utils generic, so the user can do something like toDartObject<List<int>> and we do the casting internally.

    Obviously option 2 is better, I'm just not 100% sure it's possible using Dart's generics. See what you can do.

  9. Siya-05 commented on Sep 14, 2026

    @Siya-05
    Contributor

    @liamappelbe, I experimented with making the Java -> Dart collection converters generic. A helper like JList<JObject?>.toDartList() works for one-level conversions such as List<int?>, including nulls.

    For nested types like List<List>, Dart preserves T = List but I couldn't find a way to generically extract the inner type argument, so the recursive conversion produces List<Object?> and the cast fails.

    I tried allowing an optional element converter:
    toDartList({T Function(JObject?)? convertElement, ...})
    which allows nested typed conversions by supplying the nested conversion explicitly. Is this a valid approach?

  10. liamappelbe commented on Sep 14, 2026

    @liamappelbe
    ContributorAuthor

    Ok, then maybe a util that returns List<Object?> that the user can manually .cast() is the best approach (I can see I typo'd that in my previous comment as List<JObject?>, but yeah, JObject won't work for primitives).

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueA good starting issue for contributors (issues with this label will appear in /contribute)lang-javaRelated to Java supportpackage:jnipackage:jnigen

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions