Repository navigation
JavaCallableWrapperGenerator uses XML? #11921
Description
Activity
Just some notes that were raised:
- The linker (generally) only runs on Release builds, so this would not help Debug builds
- We would still need to use Cecil (or something) for Debug builds to build the wrappers
More recent random thoughts…
We're now ".NET", not Xamarin.Android, and as part of that migration we now use the .NET linker in the Release configuration.
The .NET linker runs a pipeline of linker steps, which .NET Android controls via the
@(_TrimmerCustomSteps)item group.A thought of ours, to "force" cleanup of the
<GenerateJavaStubs/>task, is to move Java Callable Wrapper generation into a linker pipeline step. (This feels quite plausible and sane.).NET Android Debug builds also need to do "linker-like" things, such as
GC.KeepAlive()insertion for older binding assemblies and fixing "missing" abstract methods, so it occurs to us that Debug builds could also use a (shorter!) linker pipeline, which could also be used to emit Java Callable Wrappers. (The big unknown here is performance: how much slower would this be? Could we have an "in-process linker pipeline"?)If these ideas pan out, it means that this idea is moot: there wouldn't need to be an XML intermediary, because Java Callable Wrapper generation would be a linker step which could run before
[Register]is removed, and then[Register]could be removed in a subsequent linker step in the same pipeline. Furthermore, the .NET linker already uses Cecil, so use of Cecil would not be a new concern.- added a commit that references this issue
on Feb 21, 2024 We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
This issue will now be closed since it had been marked "possibly-stale" but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.
- locked and limited conversation to collaborators
on Aug 15, 2026
Context: https://xamarinhq.slack.com/archives/C03CEGRUW/p1574437340441800
Java.Interop.Tools.JavaCallableWrappers.JavaCallableWrapperGeneratorreads assemblies viaMono.Cecilin order to write Java Callable Wrappers.Is this actually desirable?
One of the impacts to this decision is that the Xamarin.Android linker can't fully link; it must preserve
[Register]custom attributes so that the Java Callable Wrappers can be generated, and then a later linker step must be run to remove all of the[Register]attributes:There have also been mutterings of migrating parts of the
<GenerateJavaStubs/>task to use System.Reflection.Metadata from Cecil, or to make it suitable for use with Incremental Builds.It may be desirable to have
JavaCallableWrapperGeneratorinstead process an XML description of the types to generate, possibly using the same XML format asgenerator'sapi.xmlfiles, and then update the linker to generate this XML file as part of it's operation.This would allow
JavaCallableWrapperGeneratorto not useMono.Cecilin order to operate, which may be desirable.