Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Java.Interop] Converge Android interop implementations and eliminate duplicate runtime paths

Đang mở
  • Có gì không ổn?
#12,995 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
15/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, java
Lĩnh vực
mobile-dev

Hướng nghiên cứu

Start by reading the two proxy implementations named in the issue: src/Mono.Android/Android.Runtime/JavaProxyThrowable.cs (with AndroidRuntime.cs) and external/Java.Interop/src/Java.Interop/Java.Interop/JavaProxyThrowable.cs plus JniEnvironment.Errors.cs, then src/Microsoft.Android.Runtime.NativeAOT/Java.Interop/JreRuntime.cs and UncaughtExceptionMarshaler.cs. Run the focused BuildProguardEnabledProject test in src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest2.cs under both CoreCLR and NativeAOT to see the current runtime-specific assertions. Done means both runtimes dispatch through android.runtime.JavaProxyThrowable with the listed round-trip, stack-trace and peer-lifetime tests passing, and the unused proxy/JAR/typemap plumbing removed. This is multi-phase architectural work; the first task is producing the inventory and split into focused PRs, not making an edit.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

needs-triage
Android framework version

net11.0-android (Preview)

Affected platform version

Current dotnet/android development sources; CoreCLR and NativeAOT. This is an architectural cleanup proposal, not an OS-specific failure.

Description

Move Java.Interop and Mono.Android toward a single coherent Android interop implementation, eliminating historical "two ways of doing things" where the split is no longer necessary.

Direction: Android's supported runtime requirements should drive this work. Preserving Java.Interop independently of Android is not, by itself, a reason to retain duplicate implementations. Preserve required semantics and public contracts, rather than maintaining parallel internal mechanisms solely because of their historical ownership.

This should be incremental follow-up work, separate from PR #12890. Aligning behavior need not wait for an assembly merge; evaluate assembly/dependency consolidation separately if it meaningfully simplifies the architecture.

First concrete target: exception proxies

CoreCLR dispatch uses Android.Runtime.JavaProxyThrowable, backed by android.runtime.JavaProxyThrowable. NativeAOT creates JreRuntime and inherits Java.Interop's exception dispatch, which uses Java.Interop.JavaProxyThrowable, backed by net.dot.jni.internal.JavaProxyThrowable.

These paths differ in more than the Java name: creation, managed-exception unwrapping, stack-trace translation, and uncaught-exception reporting need to agree. Java.Lang.Throwable.FromException() already creates the Android platform proxy.

Removing the legacy platform JAR in #12890 exposed this split in an R8 packaging test. The immediate test fix correctly checks each runtime's current proxy, but does not resolve the architectural duplication. Both runtime/RID variants pass with that fix, and Java-to-managed-to-Java exception propagation was verified locally for both runtimes.

  • Converge CoreCLR and NativeAOT on one Android exception-proxy implementation, preferably the existing android.runtime.JavaProxyThrowable.
  • Unify creation and unwrapping across runtime dispatch, direct Java.Interop exception-throwing APIs, and NativeAOT uncaught-exception reporting. Do not change only the Java class name or one runtime override.
  • Retain original managed exceptions and their identity where supported, preserve Java exceptions, and define consistent message/stack-trace behavior.
  • Ensure real NativeAOT reachability retains the generated platform peer and its required constructors under ILC and R8; do not restore the legacy platform JAR.
  • Once all consumers are migrated, remove the redundant proxy implementation and associated generated-Java, JAR, typemap, native JNI lookup, and keep-rule plumbing that is genuinely unused.

Broader convergence audit

Inventory remaining parallel mechanisms for proxy creation/unboxing, peer lifetime and GC bookkeeping, activation/type resolution, Java generation, and runtime packaging. For each, identify whether the difference is required by CoreCLR/NativeAOT or merely historical, then split actionable consolidation work into focused PRs.

Do not assume apparently similar implementations are interchangeable: for example, managed-object proxy equality/hash-code/string-conversion semantics need an explicit decision before consolidation.

Related: #11727 — Remove support for experimental JavaInterop1 codegen. Coordinate with that work and revisit its standalone-preservation assumptions rather than creating contradictory cleanup plans.

Acceptance criteria for the exception-proxy phase

Both runtimes use the same Android proxy for managed exception dispatch. Tests cover original-exception round-trips, exported methods and throwing constructors, nested callbacks, uncaught-exception reporting/events, stack traces, pending-exception cleanup, and peer/reference lifetime. Release builds with and without R8 retain the required peer/constructors; obsolete proxy artifacts are absent after their consumers have been removed. Runtime-specific assertions remain only where there is a documented, necessary behavioral difference.

Steps to Reproduce

This is a convergence proposal rather than a new failure report. The current split can be inspected in:

  • src/Mono.Android/Android.Runtime/AndroidRuntime.cs and JavaProxyThrowable.cs.
  • src/Mono.Android/Java.Lang/Throwable.cs.
  • src/Microsoft.Android.Runtime.NativeAOT/Java.Interop/JreRuntime.cs and UncaughtExceptionMarshaler.cs.
  • external/Java.Interop/src/Java.Interop/Java.Interop/JniRuntime.cs, JniEnvironment.Errors.cs, JavaProxyThrowable.cs, and JniRuntime.JniValueManager.cs.
  • src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest2.cs, test BuildProguardEnabledProject.
Did you find any workaround?

PR #12890's runtime-specific DEX assertions reflect the current supported behavior. They are an immediate test correction, not the proposed convergence. No legacy compatibility path needs to be restored.

Relevant log output

N/A. The investigation, focused fix, exact validation commands, and local results are recorded in this PR comment.

Ngôn ngữ chính
C#
Star
2.1k
Fork
579
Merge trung bình
2 ngày 3 giờ
Pull request đã merge (30 ngày)
216

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/android

Tất cả issue của dotnet/android

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.