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

Annotated JDK: Collections.sort's list, StringBuilder.indexOf, Throwable.printStackTrace(PrintWriter) have wrong or missing modification verdicts

Cerrado
  • ¿Algo no está bien?
#64 5 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
tooling

Línea de trabajo

Start in the annotated JDK under maddi-aapi-archive for JavaUtil.java around the Collections.sort stubs (lines 1628 and 1631) and JavaLang.java for StringBuilder/AbstractStringBuilder query methods and Throwable.printStackTrace(PrintWriter). Match existing @Modified / @NotModified / @IgnoreModifications patterns on sibling methods. Add a small analyzer test per item so Collections.sort(l) is a decided modification of l and indexOf / printStackTrace(PrintWriter) leave the receiver unmodified.

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

Descripción

bug engine:analyzer

Three gaps in the annotated JDK (maddi-aapi-archive/.../jdk), found while building diagnostics on the modification analysis downstream (equals/toString/compare that change state, loops that modify their collection). Each makes the analysis read a method as modifying something it does not, or leaves a real modification undecided.

1. Collections.sort — the list parameter has no verdict

JavaUtil.java:1628 and :1631:

static <T extends Comparable<? super T>> void sort(/*@Independent[M]*/ List<T> list) { }
static <T> void sort(...)

The list parameter carries no modification annotation, so UNMODIFIED_PARAMETER is absent and a caller gets the shallow default. Collections.sort(x) does modify x: it should be marked @Modified, like List.sort's receiver effectively is.

2. StringBuilder.indexOf (and siblings) — not marked non-modifying

JavaLang.java:2461, :2464 (the StringBuilder$ overrides from AbstractStringBuilder; compare :1853–:1859 and :2246–:2249):

int indexOf(String str) { return 0; }
int indexOf(String str, int fromIndex) { return 0; }

In the annotated API a method without @NotModified is modifying, so sb.indexOf(sep) modifies sb. These are reads. The same probably holds for other query methods of AbstractStringBuilder / StringBuilder / StringBuffer (lastIndexOf, charAt, length, substring, codePointAt, …) — worth a pass over the class.

3. Throwable.printStackTrace(PrintWriter) — not marked non-modifying

JavaLang.java, in Throwable$:

@IgnoreModifications void printStackTrace() { }
@NotModified void printStackTrace(/*@Independent[M]*/ PrintStream s) { }
void printStackTrace(PrintWriter s) { }

The PrintStream overload is @NotModified; the PrintWriter one is not, so t.printStackTrace(new PrintWriter(sw)) modifies t. It should match its sibling (the writer is what changes, not the throwable).

How it shows

Downstream, jenkins' WorkspaceList.Entry.toString() → Functions.printThrowable(source) → t.printStackTrace(new PrintWriter(sw)) read as "toString modifies source"; fernflower's TextBuffer.toString() → myStringBuilder.indexOf(...) read as "toString modifies myStringBuilder"; a Comparator.compare doing Collections.sort(x) could not be shown to modify x. The consumer now works around these (it distrusts a missing verdict outside containers and builders, and query-named methods), but the verdicts themselves are what should be right.

Suggested check

A small analyzer test per item: Collections.sort(l) leaves l modified with a decided verdict; sb.indexOf("x") and t.printStackTrace(pw) leave sb / t unmodified.

Lenguaje dominante
Java
Estrellas
1
Forks
1
Merge medio
1 h 58 min
PR fusionados (30 d)
5

Preparar el entorno

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 CodeLaser/maddi

Todos los issues de CodeLaser/maddi

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.