Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[generator] Investigate Throwable constructor-chain and partial-hook lifecycle coverage

Abierto
  • ¿Algo no está bien?
#13,334 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp, java
Área
devtools, testing-qa

Línea de trabajo

Start with PeerConstructorPartialMethod_Class in CodeGeneratorTests.cs, then trace forwarding and initializer selection in BoundClass.cs and BoundConstructor.cs; compare the Streams IOException snapshot. Run the generator tests, then investigate a two-level Throwable hierarchy on a real Android/JNI runtime. Done means focused output and lifecycle coverage distinguishes hook count/order and peer validity without treating compile-only probes as native coverage.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Area: Mono.Bindings needs-triage
Android framework version

net11.0-android (Preview) — generator and runtime coverage follow-up; also distinguish legacy compilation from updated memory-safety-rules probes.

Affected platform version

Binding-constructor preparation reviewed in #13190 at commit e4473175aba5271fd839d0a1dd8b3777a8ca5f90. This is a coverage gap, not an observed runtime regression.

Description

Follow-up to https://github.com/dotnet/android/pull/13190#discussion_r4415013169.

Investigate and improve coverage of generated Throwable construction through the internal JniObjectReferenceOptions.None forwarding route, especially with inheritance and peerConstructorPartialMethod hooks.

The existing PeerConstructorPartialMethod_Class test checks emitted text for an ordinary Object-derived class. The Streams IOException snapshot has a forwarding declaration but no bound Java constructors or partial hooks. Earlier session-only generated-chain/compiler probes covered constructor selection and implementation/reference accessibility, not actual hook execution order or real Java-peer creation. Passing compiler probes must not be presented as native lifecycle coverage.

A focused follow-up should investigate a two-level generated Throwable inheritance chain with bound Java constructors and hooks, then add appropriately scoped coverage for:

  • Ordinary managed constructors selecting the None forwarding route.
  • Hooks running exactly once, in base-to-derived order, before a Java peer is installed.
  • Normal construction subsequently yielding a valid Java peer.
  • Existing initialization, dispatch and cleanup behavior remaining intact.

Separate generator-output assertions from actual Android/JNI lifecycle tests; a synthetic handle or compile-only peer model does not prove a valid native peer.

The originating PR is an unsafe audit, not a general refactoring or test-coverage expansion. No behavioral bug has been demonstrated here, and the user explicitly requested tracking this improvement separately. This issue is also distinct from the known cross-assembly updated-rules constructor-initializer limitation: internal forwarding does not provide external assemblies with an accessible safe base constructor, and the corresponding CS9362 probe remains an unresolved design boundary, not a runtime failure reproduced by this issue.

Relevant source:

  • external/Java.Interop/tools/generator/SourceWriters/BoundClass.cs: forwarding constructor and partial hook emission.
  • external/Java.Interop/tools/generator/SourceWriters/BoundConstructor.cs: initializer selection and JNI peer construction.
  • external/Java.Interop/tests/generator-Tests/Unit-Tests/CodeGeneratorTests.cs: PeerConstructorPartialMethod_Class.
  • external/Java.Interop/tests/generator-Tests/expected.xaji/Streams/Java.IO.IOException.cs.
  • external/Java.Interop/Documentation/Architecture.md: generated managed binding safety and cross-assembly limitation.
Steps to Reproduce
  1. Inspect the existing hook test and Streams IOException fixture to confirm the missing combined inheritance/constructor/hook case.
  2. Generate a two-level Throwable subclass chain containing bound Java constructors and distinct partial construction hooks.
  3. Check initializer selection and hook emission in actual generated output.
  4. Run the generated hierarchy against a real Android/JNI runtime, recording hook count/order and peer state before and after construction.
  5. Document findings and add focused regression/coverage tests appropriate to any behavior demonstrated. Do not silently change constructor accessibility, public API, caller contracts or language settings to make the tests pass.
Did you find any workaround?

N/A. No runtime failure or workaround has been established; the current gap is missing focused behavioral coverage.

Relevant log output

N/A. No failing lifecycle trace is available. Existing compile/accessibility evidence does not establish hook execution or native peer validity.

Lenguaje dominante
C#
Estrellas
2.1k
Forks
579
Merge medio
1 d 16 h
PR fusionados (30 d)
258

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/android

Todos los issues de dotnet/android

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.