You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"Sort Member: Avoid Volatile Changes" - doesn't enable to sort members alphabetically #3990
I have disabled "Sort Member: Avoid Volatile Changes" in the hope I will be able to sort my members alphabetically, as I did for decades with Eclipse and Intellij.
I am aware of the "already sorted" thing that the source action point "Sort members for Example.java" doesn't show up when the file is already sorted. I understand this means "already sorted regarding the types and visibility of the members", as alphabetical sorting inside a type or visibility group is not enabled per default.
I expected that if I disable "Sort Member: Avoid Volatile Changes" alphabetical sorting is enabled by own risk, and also the source action menu item "Sort members of Example.java" will show up if the members are sorted correctly against types, etc, but NOT alphabetically.
Further, this issue was closed where it was mentioned as "supported", which seems not to be the case for alphabetical sorting: microsoft/vscode-java-pack#916
I am not sure if this is a bug or intentionally, in the second case I want to set this circumstance as a feature request. But it strongly feels to me as a bug, because I can not see any meaning of the setting "Sort Member: Avoid Volatile Changes" otherwise. Also when I read regarding issues and search for it in the internet, several people had the same confusion regarding this and asked for it in the past.
However, we still had the option for volatile changes because it's possible to sort by things by visibility that can order elements in a way that would produce a compilation error. My guess is when microsoft/vscode-java-pack#916 was closed against the PR, it was meant that the "Sort Members" was adopted, even though the scope was reduced to exclude alphabetical sorting.
It can probably be reintroduced. SortMembersOperation would need to be moved so it would be accessible to use upstream. The good news is that the annoyance of having to add another dependency is gone thanks to eclipse-jdt/eclipse.jdt.ui#692 .
I would appreciate this feature very much.
We are currently still using Eclipse, and want to migrate towards using VSCode - and this is currently one of the (admittedly small) issues that can't be properly resolved. Eclipse sorts the methods, and the RedHat tooling does not, this causes many unnecessary diffs. Also, as we want to have the sort-by-category feature, switching off the member sorting altogether in Eclipse is no option.
Activity
rgrunber commentedon Mar 26, 2025
Looking back at eclipse-jdtls/eclipse.jdt.ls#2169 (comment) , we left out the code to do alphabetical sorting.
However, we still had the option for volatile changes because it's possible to sort by things by visibility that can order elements in a way that would produce a compilation error. My guess is when microsoft/vscode-java-pack#916 was closed against the PR, it was meant that the "Sort Members" was adopted, even though the scope was reduced to exclude alphabetical sorting.
It can probably be reintroduced.
SortMembersOperationwould need to be moved so it would be accessible to use upstream. The good news is that the annoyance of having to add another dependency is gone thanks to eclipse-jdt/eclipse.jdt.ui#692 .reuschling commentedon Mar 27, 2025
Sounds good, many thanks :)
benjamin-murauer-esd commentedon Apr 13, 2026
I would appreciate this feature very much.
We are currently still using Eclipse, and want to migrate towards using VSCode - and this is currently one of the (admittedly small) issues that can't be properly resolved. Eclipse sorts the methods, and the RedHat tooling does not, this causes many unnecessary diffs. Also, as we want to have the sort-by-category feature, switching off the member sorting altogether in Eclipse is no option.