Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#64 5 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
1
Fork
1
Merge trung bình
1 giờ 55 phút
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CodeLaser/maddi

Tất cả issue của CodeLaser/maddi

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.