Annotated JDK: Collections.sort's list, StringBuilder.indexOf, Throwable.printStackTrace(PrintWriter) have wrong or missing modification verdicts
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Java
- Stars
- 1
- Forks
- 1
- Avg merge
- 2h 51m
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CodeLaser/maddi
-
build/ci good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Java → C# translation: an idiomatic C# printer driven by the modification and nullability analysesOpenenhancement extension front-end:csharp
Difficulty 5/5 Over a week Newbie friendliness 8/100
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 40/100
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Similar issues
-
enhancement good first issue
Difficulty 2/5 Half a day Newbie friendliness 66/100
apache/fineract-consumer-facing#175 ·
Maintainers usually reply within 1 day
-
[BUG] 订单：会员凭订单号即可取消其他会员的待付款订单（取消接口不校验订单归属）Possibly taken @dadiyang claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
macrozheng/mall#1016 ·
-
[Bug] The producer summary counts an unreported client version as a second version and warns about a version mixPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
apache/rocketmq-dashboard#6110 ·
Maintainers usually reply within 4 days
-
Feature:Resolution
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
intellij-elixir/intellij-elixir#4396 ·
Maintainers usually reply within 1 day
-
Python 3.15 supportPossibly taken @amnesiaof claimed this today. OpenL: python L: python:uv
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
dependabot/dependabot-core#16524 · 1 comment ·
Maintainers usually reply within 1 day