Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#64 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
tooling

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
1
Fork
1
Merge medio
1h 58m
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CodeLaser/maddi

Tutte le issue di CodeLaser/maddi

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.