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

Add a binary-compatibility check to catch unintended ABI breaks between releases

Cerrado
  • ¿Algo no está bien?
#463 1 comentario 1 reacción 0 asignados Ver en GitHub

@jainruchir ya está trabajando en esto.

Desde el 17/9/2026.

  • #465 de @jainruchir — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
build-system

Línea de trabajo

Empieza inspeccionando la configuración de Groovy Gradle para los módulos java-spiffe-core y java-spiffe-provider y cómo se resuelven los artefactos publicados desde Maven Central. Configura el plugin japicmp Gradle para comparar cada módulo con su última versión publicada y, a continuación, verifica que el build marque un cambio incompatible en la API pública, permitiendo al mismo tiempo las rupturas intencionadas documentadas mediante una allowlist explícita y una nota en el changelog.

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

Descripción

Some releases change the public binary API without it being flagged as a breaking change, which surfaces for consumers as a runtime NoSuchMethodError/NoClassDefFoundError (from a jar compiled against the previous version) rather than a compile error that would be caught early.

The clearest recent example is 0.8.15: #377 removed Lombok and hand-wrote the builders, which renamed the generated builder class DefaultX509Source.X509SourceOptions.X509SourceOptionsBuilder → Builder. Code compiled against <= 0.8.14 then fails at runtime against >= 0.8.15:

java.lang.NoSuchMethodError: 'io.spiffe.workloadapi.DefaultX509Source$X509SourceOptions$X509SourceOptionsBuilder io.spiffe.workloadapi.DefaultX509Source$X509SourceOptions.builder()'

It was listed under "Dependency updates" in the 0.8.15 notes, so the ABI impact appears to have been unintentional.

Proposal

Add a binary-compatibility gate to the build that diffs each build's public API against the last published release and fails on binary-incompatible changes, applied to the consumer-facing modules (java-spiffe-core, java-spiffe-provider).

For this repo specifically (Groovy Gradle, pure Java, multi-module, published to Maven Central via com.vanniktech.maven.publish), the japicmp Gradle plugin looks like the best fit: it applies per subproject and can resolve the previous release from Maven Central as the baseline automatically, so there's no per-release config to maintain. revapi is a more powerful alternative if richer rules are ever needed, though it is likely heavier than this project requires.

This wouldn't block intentional breaking changes; it would make them explicit (an allowlist entry plus a changelog note) instead of silent, so consumers can plan for them.

We're happy to open a PR to wire this up.

Lenguaje dominante
Java
Estrellas
46
Forks
28
Merge medio
11 d 6 h
PR fusionados (30 d)
6

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin 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 spiffe/java-spiffe

Todos los issues de spiffe/java-spiffe

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.