java.lang.IllegalArgumentException: Comparison method violates its general contract! #1628
Comments
|
Same issue here, see #1606 |
|
|
It's likely to be a bug introduced in a recent Windows 11 update. I did a temporary fix: https://github.com/xxr0ss/jadx/tree/fix-broken-filedialog. |
|
@xxr0ss But this time it is not Windows 11 but 10 according to the bug report. Unfortunately I wasn't able to reproduce this bug on both Windows versions. The affected systems seem to have a special property like a special connected device (e.g. via USB) or a installed software. |
|
So as @xxr0ss in his fix uses |
|
@xxr0ss Thanks for your investigation. But I am not sure If I understand the result you have posted. If the bug is caused by JFileChooser how can switching the sort algorithm prevent it from happening? Can you give us more details on the problem or are you preparing a OoenJDK bug report? |
|
So here's the detail @jpstotz : private static final Comparator<File> FILE_COMPARATOR = new Comparator<File>() {
public int compare(File f1, File f2) {
ShellFolder sf1 = null;
ShellFolder sf2 = null;
if (f1 instanceof ShellFolder) {
sf1 = (ShellFolder) f1;
if (sf1.isFileSystem()) {
sf1 = null;
}
}
if (f2 instanceof ShellFolder) {
sf2 = (ShellFolder) f2;
if (sf2.isFileSystem()) {
sf2 = null;
}
}
if (sf1 != null && sf2 != null) {
return sf1.compareTo(sf2);
} else if (sf1 != null) {
// Non-file shellfolders sort before files
return -1;
} else if (sf2 != null) {
return 1;
} else {
String name1 = f1.getName();
String name2 = f2.getName();
// First ignore case when comparing
int diff = name1.compareToIgnoreCase(name2);
if (diff != 0) {
return diff;
} else {
// May differ in case (e.g. "mail" vs. "Mail")
// We need this test for consistent sorting
return name1.compareTo(name2);
}
}
}
};You can see the return value can only be 1 or -1. And that's what the TimSort is unhappy about. public static void sort(Object[] a) {
if (LegacyMergeSort.userRequested)
legacyMergeSort(a);
else
ComparableTimSort.sort(a, 0, a.length, null, 0, 0);
}To me this is quite unusual😂!!! I've been using Java 11 for a long time, but I didn't have this problem until recently. |
|
@jpstotz I don't have an account in OpenJDK Community and I cann't even find where to sign up one😓. And I've being a bit busy lately. It'll be nice of you to report this bug to OpenJDK! |
|
@xxr0ss Thanks for the detailed explanation, I think I got the point but I have to look at the code myself because Last time I checked the Java bug tracker was still "ruled" (provided) by Oracle and they don't provide accounts unless you have contributed code to OpenJDK. Therefore for Java developers there is only an email address where you can send bug reports which will create a new issue. But without account you can't comment or anything else. I will try to create a minimal reproduceable example to demonstrate the bug. |
|
Understood👍@jpstotz I will also try to find out what's so special about the |
|
@xxr0ss Debugging Jadx and the code at According to the stack trace the error starts here: At run-time if I look into I tried to create a simple example of an Array containing special folder entries. Unfortunately the module system of Java does not allow to use/invoke |
|
@jpstotz 😵I'm sorry I messed things up!! I debugged again and static int compareShellFolders(Win32ShellFolder2 sf1, Win32ShellFolder2 sf2)Duplicated folder entries do exist on my computer! I logged // sun.awt.shell.Win32ShellFolderManager2
folders.add(desktop);
// Add all second level folders
File[] secondLevelFolders = checkFiles(desktop.listFiles());
log> Arrays.sort(secondLevelFolders);
for (File secondLevelFolder : secondLevelFolders) {You can see And I'm not sure if the return value of comparison for // sun.awt.shell.Win32ShellFolder2
public int compareTo(File file2) {
...
return Win32ShellFolderManager2.compareShellFolders(this, (Win32ShellFolder2) file2);
}This comparison returns value like below, which |
|
@jpstotz are there any ShellFolders on your computer that have the same name, while one is a special entry and the other not? I logged |
|
@xxr0ss That is indeed strange and might be the cause. I assume you are printing the elements using Can you identify which element on your Windows Desktop is creating this special documents folder entry? |
|
@jpstotz Oh! I just stopped getting the exception after I removed all special folders (Documents, Pictures ...) from Quick Access. And I went to
|
|
I came across this issue while troubleshooting the same problem for a user on a different project. Here is quite a long thread detailing that effort. If you scroll all the way to the bottom, you'll find two posts where I explain the cause. The short version is: This line in I submitted a bug report to OpenJDK earlier today. I'd encourage you to do the same; maybe we can light a fire under them to get this fixed. |
|
looks like the JDK tracks it as https://bugs.openjdk.org/browse/JDK-8305072 |
They seem to have decided to close it being unable to reproduce. |
|
@edemen if someone knows how to reproduce it.. let them know. The test code is in the bug report, what is missing is the right combination of "special" and "non special" windows folders - whatever that is. |
|
Nice. They don't need to be able to reproduce the problem to see what's wrong---it should be obvious just from reading the code. Argh. |
For a long time I had two |
|
Just a quick note to let you know I'm facing this same problem with someone using OpenJDK 21. Is there anything I can do to help? |
|
@uwemock workaround for this issue (legacy sort JVM flag: |
|
My fix was merged: openjdk/jdk#18126 It ought to appear in the next JDK release. |
Please describe what you did before the error occurred.
IMPORTANT! If the error occurs with a specific APK file please attach or provide link to apk file!
The text was updated successfully, but these errors were encountered: