Repository navigation
[Java] Collect feedback on adr-007 Java embeds Copilot CLI Rust runtime #1924
Description
Activity
This issue could not be automatically classified into one of the standard categories (bug, enhancement, question, or documentation).
It appears to be a meta/process issue — specifically a feedback-collection thread for ADR-007 rather than a report of broken behavior, a feature request, a usage question, or a documentation gap.
A human maintainer will review and handle this issue appropriately.
Generated by Issue Classification Agent for issue #1924 · sonnet46 399K · ◷
Option 2 sounds fine to me if it's considered reasonable by the Java ecosystem, and your comments suggest it is. I'd be fine with option 1 as well. We need to avoid option 3 I think; runtime downloading of required binaries seems like a non-starter for many target environments.
In the Azure SDK for Java project we have been exceedingly reticent to include native dependencies, for the reasons you mention. Despite this, with the cost cutting going on, it is often the case that there no longer exists SDK specialists in all languages, and this tends to drive the discussion more and more frequently towards a 'native core', unfortunately.
Often times my first response is "ugh, I really wish we didn't have to do that", followed by asking "how big are the native binaries?" For the reasons you outline, a native binary of ~1MB is quite a lot more palatable than a binary of 25MB, once you multiply out by number of platforms in both operating system and CPU architecture dimensions.
My preference in most cases is to create the 'uber jar', where all dependencies are bundled into one library, because that makes the downstream deployment story easier. In particular, if our customers are building libraries, if we force them to have to ship different versions of their library for each OS / CPU architecture, we are getting pretty close to externalising our organisational challenges.
In this case, it really comes down to a gut feel because I'm not sure how frequently copilot SDK will be shipped as a dependency of another library, versus being used in an end product on a single target platform. I would imagine it is possibly more towards the latter rather than the former though, which probably means option 2 is ok, especially given the size of the binaries and the resulting uber jar in option 1.
Having said that, native binaries bring many other challenges that take the user out of the Java stack - configuration, logging, http stack, debuggability / stacktraces, etc. It's always worth a little bit of a challenge on the point of "do we really need a native dependency here?", even if it is ultimately futile and can be argued away as a better option over the current approach.
That's my $0.02NZD, for whatever that is worth.
Was curious about:
- The JNA calling for Java, is this not a case for FFI via Panama (assuming a Java 25 LTS base line).
- Support for Apple x86 (which Apple themselves are dropping and Java is dropping)
Outside of that, I think that you may want to consider Option 2 and Option 1 (hopefully we can talk to some existing users/customers). I can imagine some customers wanting the smaller download and being comfortable with having their own per platform config for build/deploy time. Others may want a blanket rollout without wanting to 'fuss' over per platform details and are happy to pay the larger binary cost.
Also for option 3, is the core runtime not going to be made available as a std Linux / Windows / Mac package? It would actually almost be my preferred option, it's not uncommon for a Java program to talk to a native lib that's effectively supplied by the OS package manager as a mandatory dependency.
If the world was perfect, I'd prefer option 3, but as I'm using https://github.com/eirslett/frontend-maven-plugin all the time, and I know how annoying this is in enterprise environments, and I wouldn't go that route.
I also wouldn't use option 1, and in fact you made me now understand one of my issues with Copilot SDK: the repo is nearly 700mb, and that means when you use it with worktrees (using GitHub Copilot App to work on GitHub Copilot SDK, logically!), then that tends to take a huge space on your hard drive. And with today's hard drive prices, it's even worse.
So that leaves us with option 2, which is a good middle ground. As you publish more JARs to Maven Central, there is just one thing to be aware of: now there are (soft) limits for publishing JAR files on Maven Central, unless we have a specific agreement with them. The main one for you will be the 1,000 files limit: that seems high, but for all JAR files you'll also send JavaDocs, SHA, etc... You can reduce them a bit, but you'll need to calculate how many deployments you can do per month, and that's probably less than 10 with this use case -> there would be a risk that you want to do an emergency deployment at the end of the month (because there's a security issue), and you'll be blocked by this. Again, it's a soft limit (I'm already above it on my account this month, and I still deploy!), and that should be negotiated with Maven Central.
Option 2 is a proven method by OpenJFX / JavaFX ecosystem.
The balance of feedback is Option 2.
I actually suggest we do Option 2 and Option 1. The simplicity of having a simple single JAR is very compelling.
Was curious about:
- The JNA calling for Java, is this not a case for FFI via Panama (assuming a Java 25 LTS base line).
- Support for Apple x86 (which Apple themselves are dropping and Java is dropping)
Outside of that, I think that you may want to consider Option 2 and Option 1 (hopefully we can talk to some existing users/customers). I can imagine some customers wanting the smaller download and being comfortable with having their own per platform config for build/deploy time. Others may want a blanket rollout without wanting to 'fuss' over per platform details and are happy to pay the larger binary cost.
Also for option 3, is the core runtime not going to be made available as a std Linux / Windows / Mac package? It would actually almost be my preferred option, it's not uncommon for a Java program to talk to a native lib that's effectively supplied by the OS package manager as a mandatory dependency.
Good instinct — FFM is probably where this lands eventually, but not in this iteration, for three reasons:
- We support Java 17, where FFM doesn't exist, so JNA is required anyway; FFM would be a second parallel implementation.
- FFM pushes
--enable-native-accessonto every consumer's launcher as JEP 472 tightens; JNA is zero-config for downstream users today. - The C ABI surface is ~12 fixed entry points carrying JSON-RPC strings, so JSON serialization dominates and FFM's call-overhead advantage is unmeasurable here. Bidirectional callbacks also add FFM
Arena/upcall-lifetime complexity that JNA'sCallbackhandles for free.
We're abstracting the binding layer behind an internal interface, so swapping in FFM later (once the baseline and JEP 472 timeline make it the clear win) is a contained change rather than a rewrite. Happy to expand any of this into the ADR if useful.
Reacted by Martijn Verburg- added a parent issue
on Jul 30, 2026
This issue captures any comments for ADR-007-java-rust-embedding-strategy.