Doubt Regarding LLM Java/Kotlin to API

[Adarsh Raj]

I had a doubt regarding the approach for JNIgen-based Java/Kotlin to Dart conversion, mentioned in the ideas list.

"Or do we need to teach an AI how to run JNIgen and make it generate code that is subsequently analyzed with the Dart analyzer, feeding errors back into the AI to improve its answer?"

My concern is—is this step needed? The main task is to handle language-specific syntax changes between Java/Kotlin and Dart, while class structures (initializations and usage) remain untouched. Since JNIgen already reuses the same classes from the Java/Kotlin API, explicitly generating and sending JNI bindings would only increase token cost without adding real value. Instead, we can achieve the same result with a simple prompt instruction:
"Assume JNI bindings are generated for all the Java classes."

Would this approach be sufficient, or should I still consider integrating AI-driven validation?

Looking forward to your guidance.

Best regards,
Adarsh Raj

[Daco Harkes]

Hi Adarsh,

Well, it depends on what the quality of the output is.

With your current prompt, is the code that the AI generates correctly calling the API that's generated by JNIgen? Where does it succeed? Where does it fail? Does it correctly handle releasing the JObjects?

Kind regards,

 •  Daco Harkes
 •  Software Engineer
 •  dacoh...@google.com 

--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/286229ab-d921-465e-a6cc-796891076448n%40googlegroups.com.

[Adarsh Raj]

In one of the previous discussions (11th March) regarding the JNIgen to Dart code translation project, you mentioned that we could assume the JNI bindings were already in place and focus on the code conversion. However, you've raised a valid point that the JNI bindings generated may contain crucial information. Passing this as context (or generating the bindings using AI) could certainly help in producing better Dart code.

I’ve attempted generating some jni_bindings.dart files, including a basic example showcased in my proposal and another example found here, which seems to be working well with the current test prompt. However, for more thorough testing with more complex cases and my conclusion based on that, I would need some additional time.

Regarding the proposal, the timeline mentioned in the idea’s list suggests having it finalized by April 2nd. Due to ongoing papers and project submissions, would it be possible to extend the deadline for this specific aspect (passing the jni_bindings.dart to AI as context) to April 6th or 7th? As the final date of Gsoc submission is 8th April 18:00 UTC.

Additionally, I would greatly appreciate it if you could review my proposal for any additonal insights or comments. I have added tags for convenience. You can access the proposal here.

Thank you for your time and feedback!

Best regards,
Adarsh Raj

[Daco Harkes]

Hi Adarsh,

The deadline is April 8th.

The 2nd April is probably a copy-paste from last year, sorry about that!

Kind regards,

 •  Daco Harkes
 •  Software Engineer
 •  dacoh...@google.com 

To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/b989ebba-337d-4f65-854a-31eafcb6dad7n%40googlegroups.com.

[Mahesh Hegde]

> My concern is—is this step needed? The main task is to handle language-specific syntax changes between Java/Kotlin and Dart, while class structures (initializations and usage) remain untouched. Since JNIgen already reuses the same classes from the Java/Kotlin API, explicitly generating and sending JNI bindings would only increase token cost without adding real value. Instead, we can achieve the same result with a simple prompt instruction:

Excuse me for barging into the conversation.

The problem here I guess would be that - the LLM has not much idea how to idiomatically _call_ JNI bindings generated by jnigen. Probably claude or GPT-4o may have enough parameters to remember the specifics but jnigen generated code would be still rare in their training set.

Let's say you have a method

void SendNotification(ApplicationContext context, String title, String header);

claude or whichever LLM is probably having no idea how to obtain - application context, or convert `title` into java strings, or free resources between call boundary etc.. etc..

So there are two techniques I can think of, which may complement each other.

1. your system prompt should be detailed enough to tell the specifics of how jnigen generates code. I'd assume claude / GPT 4o / Gemini 2.0 flash would have enough "intelligence" to understand a prompt such as

```

Assume you have dart bindings for the android SDK java function <xyz>

{{ function signature }} {{ docs }}

The bindings follow a regular pattern to map java functions into python functions

* Java primitives will be mapped to dart primitives

* Java strings will be mapped to `jstring` type which can be created from a dart string by calling toJString() extension method

* Java arrays will be mapped to Dart `List` type.

* other Reference types in Java will be mapped to a class of same name, imported from a file which follows the pattern [[ insert an example ]]

```

This can be viable with SOTA models, although I don't think it would work with something with LLaMa 3.2 or Deepseek distills running on ollama. - These are pretty dumb in my experience.

Approach 2:

Pass the generated function signatures (hopefully signatures only) to the LLM

Modern LLMs have good context length (128K tokens is possible and I think gemini 2.0 flash supports more).

Still if you pass more than necessary information LLM will perform worse. (just like us :) ) Another important thing is cost. With claude you will go bankrupt if you include 128K tokens.

IIRC some coding assistants use some sort of vector search to find only required functions and include them in context.

You can also see what Aider (open source) does - I heard it uses some sort of AST grepping. I think that's a better approach because you don't need to generate embeddings or ship a vector storage library with your tool.

It should be possible to mix and match the above 2 approaches. I would say stick with SOTA LLMs for now, and focus on providing __relevant__ context and __background__ to the LLM.

Regards,

Mahesh

To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/CAHFkKc8hLn_3-ngCyKrWfVbcCk5Ez93%2B%2BqH%3D%2BNVHhM7VpEfTsw%40mail.gmail.com.

[Adarsh Raj]

The point you raised is incredibly insightful and spot on.

Regarding whether or not JNI bindings need to be passed to the LLM—my main concern was this: if we ask the LLM to generate JNI bindings on its own, we’re entering a whole new domain that’s highly error-prone. There’s no reliable way to ensure the bindings are correctly generated, especially given how subtle JNIgen’s conventions can be.

You beautifully presented two workarounds to this challenge:

Approach 1:

This is absolutely essential. By crafting a detailed system prompt that explains how JNIgen maps Java/Kotlin types to Dart, we can give the LLM the background knowledge it needs to use the bindings correctly. This includes conventions like .toJString() for strings, class name mapping, etc...
This is exactly the kind of setup I proposed in my proposal—providing the LLM with just enough context to make accurate conversions without bloating the prompt.

Approach 2:

I see the value in this, especially for ensuring accuracy by passing exact function signatures. However, I’m slightly skeptical about its feasibility in the long run, particularly for our end goal of building a seamless dev tool.

Incorporating an extra step where developers need to manually copy and paste function signatures into the prompt could end up being a usability bottleneck. It disrupts the workflow, that small friction point could be the deciding factor in whether the tool is adopted or abandoned.

Since generating bindings autonomously is risky, and asking the dev to supply them is cumbersome, Approach 1 becomes not only the preferred path, but also the only one that fits both correctness and UX goals. That’s also the direction I’ve committed to in my proposal, and your explanation reinforces that decision, giving me some confidence :).

Thanks again for explaining these points so clearly!